Time Nick Message 00:04 luiz hello. I found a error with basic_signs, the recipes for a kind signs shows unknown item at recipes with the string steel:sheet_metal. Whats happen? May someone help me? 00:11 luiz I already download again and try a mod called Steel, but doesn't work 00:23 rubenwardy there's probably alternative recipes that are still being registered even when the mod isn't installed 00:23 rubenwardy do you have basic matierlas installed? Without looking, I bet it uses that 00:24 rubenwardy ah that's a hard requirement so yes 00:25 luiz yes, I have basic materials. He shows two recipes, I guess is the same recipe, but in the first appears with unknow item 00:25 rubenwardy it'll be the second then 00:25 rubenwardy which craft guide are you using? the one in MTG? 00:26 luiz I'm using i3 inventory 00:26 luiz maybe the inventory with trouble with this recipe? 00:28 luiz I tryed with MTG it's ok, is i3 inventory 00:31 luiz I like so much i3 inventory :-) 13:21 definitelya Mother nature seems to be the biggest troll; I always try to replant when I cut trees in-game, but this time the tree vaporized half of my chests whit its bugged schematic... 13:22 definitelya *with 15:51 Goobax[m]1 AFCM: 20:00 erle mugli[m] ROllerozxa are you interested in giving me feedback on this? https://github.com/minetest/minetest/pull/12592 20:00 erle sorry. i meant muurkha 20:01 erle i have followed your advice and made a proof-of-concept that is *extremely* crude right now, but vastly exceeds the capabilities of the current build on GNU/Linux (x86) in terms of build correctness and not rebuilding files unnecessary 20:01 erle and it also allows to export the actual build graph in graphviz format 20:02 erle like, the real one, not the one that cmake believes is there 20:20 schwarzwald[m] Hello. 20:21 erle hi 20:21 schwarzwald[m] I can't see earlier messages. 20:21 erle schwarzwald[m] what system do you have? and does my PR work on your machine or not? 20:21 schwarzwald[m] I may try it out later. I'm not on my Debian workstation right now. 20:22 schwarzwald[m] I work with 3 GB of RAM and a Core 2 Duo IIRC. 20:22 schwarzwald[m] I'm also considering rewriting the build from scratch in either Meson or CMake as an exercise. 20:22 erle lol 20:22 erle are you the meson person? 20:23 erle because someone commented that they developed on meson in issue #11749 20:23 ShadowBot https://github.com/minetest/minetest/issues/11749 -- CMake does not capture all dependencies, causing erroneous incremental builds & build failures 20:23 schwarzwald[m] No, that was someone who actually develops Meson (I checked his PRs - he does indeed contribute to it) 20:23 schwarzwald[m] I'm unconvinced that Meson is a good idea, though. 20:23 erle i found it hilarious that that person linked a description on “here is how a better build system would work” 20:24 erle and that description was basically redo 20:24 erle but from someone who does not know redo 20:24 erle if multiple people converge on a solution, it reduces the chance that it's hipster bullshit 20:24 erle if done independently i mean 20:25 schwarzwald[m] Yeah, I would agree. 20:25 erle schwarzwald[m] i am on a core due too and have 4 GB RAM. 20:25 schwarzwald[m] That would explain why we have similar compile times. 20:25 erle be warned, my proof of concept is unlikely to reduce compile times too much rn 20:25 erle because it spends a lot of time checking dependencies 20:25 schwarzwald[m] It should reduce incremental build times. 20:26 erle that indeed 20:26 erle simply touch(1) all files 20:26 erle make or ninja will rebuild them 20:26 erle redo will not 20:26 erle switching branches is horrible right now 20:26 schwarzwald[m] I don't expect any reduction in build times from scratch, because that would have to be improved in other ways. 20:26 erle oh, i can explain 20:27 erle so the make-type way of building is two-stage 20:27 erle determine the dependencies, then toposort 20:27 erle then execute 20:27 erle redo records the dependencies after building 20:27 erle but there is a very simple implementation called “do” from avery pennarun 20:27 erle which always builds all targets 20:27 erle and simply ignores the entire dependency checking logic 20:28 erle that is why i think an incremental rebuild could be faster, it would just skip an entire part of the build (at the cost of needing another rebuild to be able to incrementally rebuild) 20:28 erle this is unlikely to save you *much* time, but given the amount of spurious rebuilds … 20:29 erle liberation circuit for example has “do” in the main repo 20:29 erle as do several other projects i know 20:29 erle because it's only 100 lines of bourne shell 20:29 erle can't get much simpler in terms of build dependencies – if you have git, you have sh 20:32 erle schwarzwald[m] this is mostly about correctness in the end 20:32 erle once it is correct, it can be made fast 20:35 schwarzwald[m] How do you keep things abstracted in Redo so that the developer can quickly make the build portable to other systems without having to worry about which dependencies are necessary? 20:37 erle schwarzwald[m] you mean other architectures or other operating systems? 20:39 schwarzwald[m] erle: yes! 20:39 schwarzwald[m] * erle: Yes! 20:40 erle schwarzwald[m] in the redo implementation i am very lazy and just alias things to “the dependency is always out of date” if i can't figure it out. i.e. if you have neither GNU coreutils nor busybox, i overbuild 20:41 schwarzwald[m] The question is how much work is involved in porting an existing application from, e.g. Linux to Windows assuming it previously only built on Linux. 20:42 schwarzwald[m] Is the developer responsible to list all link targets by hand for each platform? 20:42 erle schwarzwald[m] in dofiles, my general approach is to borrow from plan9. you can simplify a build much more, if you dont have a single build rule for a binary, but separete build rules 20:43 erle like, “build me bin/minetest.aarch64-linux-gnu” or so 20:43 erle but you can just symlink that to bin/minetest anyway 20:43 schwarzwald[m] So we would be investing more work in figuring out the build settings in order to have a more correct build later? 20:43 erle i doubt it 20:43 erle i have an aarch64 machine, so i am going to do it 20:44 erle and the trick is to *not* figure it out yourself 20:44 erle but to use whatever means you can to determine it automatically 20:44 schwarzwald[m] I can port a CMake build to that in like 0 seconds. 20:44 erle wdym 20:44 schwarzwald[m] I'm challenging you about the cross-platform capabilities of Redo. 20:44 schwarzwald[m] Our current build system handles a ton of boilerplate. 20:44 schwarzwald[m] (to which we added a ton of boilerplate because ugh) 20:45 erle i am in favor of everyone who likes cmake using cmake. i am already intending to piggyback as much on existing tools as possible. 20:46 erle schwarzwald[m] could you give me a portability example? do you mean strace? 20:46 schwarzwald[m] Alright. I'm not going to be quick to pick up a tool based on one metric and that means I'm not going to support Redo until you can clearly describe the trade-offs that are being made, in practical terms, not in theoretical terms. 20:47 erle i have a list at the top of my WIP PR that is pretty long 20:47 erle did you read that? 20:48 erle the trade-off in practical term right now is “it works on my machine more reliably than cmake, but i can't configure anything right now” 20:48 erle becauseit is a proof of concept 20:49 erle schwarzwald[m] if you can give me a concrete target to compile for that this does not work for, you have found a problem and i will likely fix it 20:50 erle but right now, it is only tested on debian gnu/linux x86 and with hardcoded CXXFLAGS and so on 20:52 erle schwarzwald[m], please only complain more once you tested it. i bet it breaks korribly as soon as someone else than me tries it in a slightly different environment. 20:52 schwarzwald[m] "schwarzwald could you give me..." <- So for example:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8644cc092f2b133640084adb2c5822300a8ad9dd) 20:52 schwarzwald[m] I don't have to touch this build script and I can compile it on PowerPC if I care to. 20:52 schwarzwald[m] I can compile it with whatever compiler I have installed, without even specifying the compiler to use. 20:53 erle yeah so? 20:55 erle schwarzwald[m] please output the dependency graph then 20:55 erle or touch all files and rebuild (it will unnecessarily rebuild) 20:56 schwarzwald[m] I'm not complaining, I'm just asking you how your cross-platform capability compares, or what the trade-offs are. 20:56 erle i happen to have tested these things quite a bit with cmake, make, ninja. the result is that there are two kinds of build systems: 20:56 erle 1. ones where you are rebuilding everything every time just to be sure 20:56 erle 2. reliable ones 20:57 schwarzwald[m] I'm not talking about theory anymore. 20:57 erle schwarzwald[m] the trade-off is that you have to have a toolchain that produces the dep information. like that the compiler can tell you that it is using libGL andwhere it is if you specify -lGL 20:57 erle cmake figures out where that library is 20:57 erle i mean the linker 20:57 erle and gives it to the linking stage with the full path 20:57 erle which obviously varies per system 20:57 erle and also allows fine-grained control 20:58 schwarzwald[m] What about transitive dependencies? 20:58 erle what about them? 20:58 schwarzwald[m] Do I have to explicitly list them for the linker to find? 20:58 erle nope 20:59 schwarzwald[m] How does the system figure out what the transitive dependencies are? 20:59 schwarzwald[m] Is it using CMake underneath or something? 20:59 erle the logic i am using is the following: a target is out of date if a) it does not exist b) it exists and there is a hash mismatch c) any of its dependencies are out of date c) any of its non-existence dependencies exist 21:00 schwarzwald[m] Right now I'm not interested in correctness. 21:00 schwarzwald[m] And I'm not interested in when/why rebuilds happen. 21:00 erle it figures it out by building it the opposite way cmake does 21:00 erle cmake needs to know the full dependency graph 21:00 schwarzwald[m] Yes, my curiosity is piqued, please elaborate. 21:01 erle look, please just take any redo implementation and look at the tool redo-ifchange. different people have implemented it differently, but the most likely thing you are going to see is that a target is out of date if its dependencies are out of date too. 21:01 erle so every dep check for a target checks all dependencies 21:01 erle and all their dependencies 21:01 erle and so on 21:02 erle you have to do this at runtime, because it is almost guaranteed to be wrong to figure it out in advance unless you freeze the entire world while building 21:02 erle wrong, but still useful 21:02 erle just not useful enough for me 21:02 schwarzwald[m] Perhaps later. I like the idea, but I think I'll stick with a more mature build system for now. 21:02 erle i have to call someone, sorry 21:03 erle well, you can do whatever you like. you were the one wanting faster rebuilds. 21:03 erle and the cmake rebuilds are not fast and if they are, they are not correct. 21:03 erle in minetests case in particular 21:04 erle anyway, i have a call 21:14 natewrench hey you know whats funny, minetest's worlds are just big shaped nodes... 62,000^3 21:46 muurkha heh 21:48 natewrench hey what is the command to fill in a set of cordinates with a block 21:49 MTDiscord if you have worldedit installed //set nodename 21:50 natewrench I dont have worldedit ill have to get it 21:53 natewrench hey Jonathon are you on the discord minetest? I dont see a channel 23:02 MTDiscord yes