| Time |
Nick |
Message |
| 00:00 |
|
luiz joined #minetest |
| 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 :-) |
| 00:51 |
|
luiz joined #minetest |
| 01:33 |
|
Lesha_Vel joined #minetest |
| 02:14 |
|
YuGiOhJCJ joined #minetest |
| 03:01 |
|
est31 joined #minetest |
| 03:54 |
|
est joined #minetest |
| 03:56 |
|
Lesha_Vel joined #minetest |
| 04:00 |
|
YuGiOhJCJ joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:10 |
|
sys4 joined #minetest |
| 05:34 |
|
erle joined #minetest |
| 05:41 |
|
calcul0n joined #minetest |
| 05:49 |
|
Verticen joined #minetest |
| 05:58 |
|
Lesha_Vel_ joined #minetest |
| 06:03 |
|
Trifton joined #minetest |
| 06:12 |
|
Trifton joined #minetest |
| 06:28 |
|
lemonzest joined #minetest |
| 06:46 |
|
olliy joined #minetest |
| 07:05 |
|
orwell96 joined #minetest |
| 07:06 |
|
definitelya joined #minetest |
| 07:27 |
|
book` joined #minetest |
| 08:04 |
|
sys4 joined #minetest |
| 08:05 |
|
fling joined #minetest |
| 08:25 |
|
___nick___ joined #minetest |
| 08:45 |
|
est31 joined #minetest |
| 09:00 |
|
specing_ joined #minetest |
| 09:04 |
|
Warr1024 joined #minetest |
| 09:05 |
|
fling joined #minetest |
| 09:32 |
|
calcul0n joined #minetest |
| 09:43 |
|
Fixer joined #minetest |
| 10:14 |
|
toluene joined #minetest |
| 12:44 |
|
sys4 joined #minetest |
| 13:00 |
|
mazes_80 joined #minetest |
| 13:16 |
|
est31 joined #minetest |
| 13:16 |
|
fling joined #minetest |
| 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 |
| 13:24 |
|
cation joined #minetest |
| 13:29 |
|
sys4 joined #minetest |
| 13:37 |
|
mazes_83 joined #minetest |
| 13:40 |
|
mazes_80 joined #minetest |
| 13:42 |
|
sys4 joined #minetest |
| 14:50 |
|
Yad joined #minetest |
| 15:05 |
|
fluxionary joined #minetest |
| 15:06 |
|
Thermoriax joined #minetest |
| 15:09 |
|
fling joined #minetest |
| 15:19 |
|
orwell96_ joined #minetest |
| 15:50 |
|
Goobax[m]1 joined #minetest |
| 15:51 |
Goobax[m]1 |
AFCM: |
| 16:44 |
|
Fixer joined #minetest |
| 16:57 |
|
Fixer joined #minetest |
| 17:03 |
|
proller joined #minetest |
| 17:32 |
|
est31 joined #minetest |
| 17:33 |
|
TomTom joined #minetest |
| 17:34 |
|
Fixer joined #minetest |
| 17:52 |
|
Fixer_ joined #minetest |
| 17:59 |
|
Guest7845 joined #minetest |
| 17:59 |
|
Guest7845 joined #minetest |
| 18:23 |
|
Fixer joined #minetest |
| 18:28 |
|
Fixer_ joined #minetest |
| 18:32 |
|
Fixer joined #minetest |
| 18:36 |
|
Verticen joined #minetest |
| 18:59 |
|
orwell96 joined #minetest |
| 19:55 |
|
Evergreen joined #minetest |
| 20:00 |
erle |
mugli[m] ROllerozxa are you interested in giving me feedback on this? https://github.com/minetest/minetest/pull/12592 |
| 20:00 |
|
est31 joined #minetest |
| 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] joined #minetest |
| 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] |
<erle> "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 |
|
specing joined #minetest |
| 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:09 |
|
natewrench joined #minetest |
| 21:14 |
|
detrout joined #minetest |
| 21:14 |
natewrench |
hey you know whats funny, minetest's worlds are just big shaped nodes... 62,000^3 |
| 21:20 |
|
cation joined #minetest |
| 21:24 |
|
est31 joined #minetest |
| 21:31 |
|
sys4 joined #minetest |
| 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 |
<Jonathon> if you have worldedit installed //set nodename |
| 21:50 |
natewrench |
I dont have worldedit ill have to get it |
| 21:52 |
|
sparky4 joined #minetest |
| 21:53 |
natewrench |
hey Jonathon are you on the discord minetest? I dont see a channel |
| 21:57 |
|
cation joined #minetest |
| 21:58 |
|
sparky4 joined #minetest |
| 22:01 |
|
est31 joined #minetest |
| 22:03 |
|
fling joined #minetest |
| 22:12 |
|
est31 joined #minetest |
| 22:35 |
|
panwolfram joined #minetest |
| 22:45 |
|
wallabra_ joined #minetest |
| 22:46 |
|
Lesha_Vel joined #minetest |
| 22:49 |
|
est31 joined #minetest |
| 22:50 |
|
fling joined #minetest |
| 22:59 |
|
sys4 joined #minetest |
| 23:02 |
MTDiscord |
<Jonathon> yes |
| 23:08 |
|
wallabra_ joined #minetest |
| 23:13 |
|
vampirefrog joined #minetest |
| 23:52 |
|
WhiskeyPotato joined #minetest |
