| Time |
Nick |
Message |
| 00:24 |
|
v-rob joined #minetest |
| 00:59 |
|
smk joined #minetest |
| 02:09 |
MTDiscord |
<kimapr> convert to STRINGS, not tables. |
| 02:10 |
MTDiscord |
<kimapr> then its just a == |
| 02:11 |
MTDiscord |
<kimapr> actually, is the order of meta entries in itemstrings defined? |
| 02:11 |
MTDiscord |
<kimapr> how does to_string decide the order to put them in |
| 02:13 |
|
olliy joined #minetest |
| 02:16 |
|
sparky4 joined #minetest |
| 02:40 |
|
Verticen joined #minetest |
| 03:13 |
|
Trifton joined #minetest |
| 03:14 |
|
v-rob joined #minetest |
| 03:20 |
|
fling joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:12 |
|
fling joined #minetest |
| 04:33 |
|
asdflkj_sh joined #minetest |
| 05:14 |
|
fling joined #minetest |
| 05:15 |
|
calcul0n joined #minetest |
| 06:12 |
|
fling joined #minetest |
| 06:18 |
|
v-rob joined #minetest |
| 06:33 |
MTDiscord |
<luatic> no, the order is not define; converting to string does not work |
| 06:33 |
MTDiscord |
<luatic> ItemStackMetaData uses typedef std::unordered_map<std::string, std::string> StringMap;, which does hashing in the end |
| 06:46 |
|
Flabb joined #minetest |
| 07:14 |
|
Noisytoot joined #minetest |
| 07:57 |
|
appguru joined #minetest |
| 08:40 |
|
fling joined #minetest |
| 09:14 |
|
fling joined #minetest |
| 09:29 |
|
fling joined #minetest |
| 10:51 |
|
TomTom joined #minetest |
| 11:08 |
|
proller joined #minetest |
| 11:13 |
|
Noisytoot joined #minetest |
| 11:18 |
MinetestBot |
[git] SmallJoker -> minetest/minetest: Content tab: Fix content download broken by bc3dccc b5e7280 https://github.com/minetest/minetest/commit/b5e7280708221cdcca89df7d16f2aea19e4b3c4c (2022-09-16T11:01:23Z) |
| 11:20 |
MinetestBot |
[git] Wuzzy2 -> minetest/minetest: Add paramtype2s for 4 horizontal rotations and 64 colors (#11431) 1d04903 https://github.com/minetest/minetest/commit/1d04903c1973591e795d3275b900d76d7cb7877a (2022-09-16T11:18:55Z) |
| 11:20 |
MinetestBot |
[git] vilhelmgray -> minetest/minetest: Add support for MINETEST_USERDATA environment variable (#12639) 19e9363 https://github.com/minetest/minetest/commit/19e936362aab3806a9554ab811be0562dcb41509 (2022-09-16T11:19:44Z) |
| 11:20 |
MinetestBot |
[git] savilli -> minetest/minetest: Fix UAF in craft recipes (#12763) 9428917 https://github.com/minetest/minetest/commit/942891787028d0cbce226c2af0536a18d5a37df2 (2022-09-16T11:20:14Z) |
| 11:50 |
|
definitelya joined #minetest |
| 11:51 |
|
cranezhou joined #minetest |
| 12:18 |
|
jaca122 joined #minetest |
| 13:04 |
|
proller joined #minetest |
| 13:08 |
|
Fixer joined #minetest |
| 13:33 |
|
appguru joined #minetest |
| 13:38 |
|
Noisytoot joined #minetest |
| 13:43 |
|
Noisytoot joined #minetest |
| 13:53 |
|
wallabra joined #minetest |
| 14:07 |
|
z812 joined #minetest |
| 14:21 |
|
diceLibrarian joined #minetest |
| 14:42 |
|
orwell96 joined #minetest |
| 14:56 |
|
definitelya_ joined #minetest |
| 14:57 |
|
v-rob joined #minetest |
| 15:09 |
|
v-rob joined #minetest |
| 15:26 |
|
calcul0n joined #minetest |
| 15:28 |
|
Zemtzov7 joined #minetest |
| 16:01 |
Zemtzov7 |
Hello there, I see `[ConnectionSend] con(4/1) Packet quota used up for peer_id=#, was # pkts` warnings in the server logs pretty often. What it means and is it fixable anything other way than tweaking the `connectiontreads.cpp`? (MT 5.6.0) |
| 16:18 |
muurkha |
I had that problem a lot, associated with desynchronization "lag" that sometimes made the game unplayable; other people here have said that turning on the WAL in the server's SQLite configuration, or switching it to Postgres, solved the problem for them |
| 16:18 |
muurkha |
I haven't had it lately |
| 16:19 |
sfan5 |
does it appear regularly or once in a while? |
| 16:22 |
MTDiscord |
<Warr1024> The SQLite WAL or switch to Postgres thing seems to be a big improvement on systems with a disk I/O bottleneck, such as mechanical drives or SD cards. I haven't seen evidence that it has a big impact on other bottlenecks such as compute, but would be curious if anyone has. |
| 16:22 |
muurkha |
it shouldn't affect other bottlenecks such as compute |
| 16:25 |
|
lemonzest joined #minetest |
| 16:26 |
|
Markow joined #minetest |
| 16:35 |
|
garywhite joined #minetest |
| 16:35 |
|
garywhite joined #minetest |
| 16:41 |
|
sys4 joined #minetest |
| 16:48 |
|
ely-the-kitsune joined #minetest |
| 17:05 |
Zemtzov7 |
sfan5: mainly regularly, depends on players. [if you asked it about my message] |
| 17:07 |
sfan5 |
I was |
| 17:07 |
sfan5 |
if the message appears often & repeatedly then you have a performance problem |
| 17:08 |
Zemtzov7 |
I counted 1969 warnings for 1 day... |
| 17:08 |
sfan5 |
but most likely not in the sense of "you need to throw more hardware at it", rather "a mod is doing something stupid and should be fixed" |
| 17:08 |
MTDiscord |
<luatic> was that day related to the moon landing in one way or another? |
| 17:09 |
Zemtzov7 |
depends on `max_lag` too? |
| 17:11 |
Zemtzov7 |
now its 1.45s with 6 players. Yeah we have some mods from APercy installed(blimp,ju52,pa28), probably they mostly causing lags |
| 17:25 |
|
Desour joined #minetest |
| 17:25 |
|
debiankaios joined #minetest |
| 17:53 |
|
v-rob joined #minetest |
| 18:04 |
|
FreeFull joined #minetest |
| 18:16 |
|
appguru joined #minetest |
| 18:26 |
|
est31 joined #minetest |
| 18:27 |
|
fling joined #minetest |
| 18:28 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Bump used IrrlichtMt version a428a0c https://github.com/minetest/minetest/commit/a428a0cf37581a35f9c4f81c2e71633e6cc3dbb9 (2022-09-16T17:54:59Z) |
| 18:37 |
|
FreeFull joined #minetest |
| 18:42 |
|
Sokomine joined #minetest |
| 18:43 |
|
vampirefrog joined #minetest |
| 18:44 |
|
chilledfrogs joined #minetest |
| 19:25 |
|
v-rob joined #minetest |
| 19:42 |
|
jaca122 joined #minetest |
| 20:01 |
|
farribeiro joined #minetest |
| 20:03 |
farribeiro |
I consider that luajit as a dependency is very old, the last release was in 2017 |
| 20:04 |
MTDiscord |
<ROllerozxa> most people use the latest 2.1 dev version |
| 20:05 |
farribeiro |
could be in touch with the luajit team for a new beta release or promote the stable |
| 20:06 |
MTDiscord |
<ROllerozxa> lol it's not like people haven't already tried |
| 20:06 |
MTDiscord |
<ROllerozxa> the advice from upstream luajit is to run latest commit because version numbers are obsolete |
| 20:06 |
muurkha |
heh |
| 20:07 |
farribeiro |
theses days i suggest Calinou use the latest commit of luajit |
| 20:07 |
farribeiro |
from git |
| 20:08 |
farribeiro |
Calinou maintains the flatpak minetest... https://github.com/flathub/net.minetest.Minetest/pull/43 |
| 20:09 |
farribeiro |
i try out too use lua 5.4... worked +- |
| 20:09 |
MTDiscord |
<ROllerozxa> please don't use newer PUC lua |
| 20:10 |
farribeiro |
i see... but i tested, works without big problems |
| 20:10 |
MTDiscord |
<luatic> No. |
| 20:10 |
MTDiscord |
<luatic> It's not backwards compatible and the errors are likely to be subtle. |
| 20:10 |
farribeiro |
but the contentdb fails |
| 20:10 |
MTDiscord |
<ROllerozxa> ? |
| 20:10 |
MTDiscord |
<luatic> Particularly because of the introduction of an integer type. |
| 20:11 |
MTDiscord |
<ROllerozxa> if contentdb fails that's because it's not supported. |
| 20:11 |
MTDiscord |
<luatic> Bumping Lua to 5.4 would require a major version update and dropping LuaJIT support. |
| 20:11 |
|
Desour joined #minetest |
| 20:11 |
MTDiscord |
<luatic> (oh, and fixing all of our Lua codebase and everything that interacts with it and the in the end we'll still have missed some subtle bugs) |
| 20:13 |
muurkha |
Lua is not really intended for people to update to new versions |
| 20:13 |
muurkha |
the idea is that you copy some version of Lua into your game or whatever and then just keep using that version of Lua forever |
| 20:13 |
MTDiscord |
<luatic> Where do you get that from? |
| 20:13 |
MTDiscord |
<luatic> I mean that's what everyone's been doing since 5.1 is pretty decent |
| 20:13 |
muurkha |
something or other Ierusalimschy wrote years ago |
| 20:14 |
muurkha |
unfortunately I read it many years ago so I don't have a link handy |
| 20:14 |
muurkha |
but he wants to have the freedom to make backward-incompatible changes |
| 20:14 |
MTDiscord |
<GreenXenith> We don't need to drop jit for 5.4. Openresty has a 5.4 jit fork |
| 20:15 |
Desour |
I've heard openresty is bad |
| 20:15 |
MTDiscord |
<luatic> I guess then "bump lua version" may be put on the breaking changes list |
| 20:15 |
MTDiscord |
<GreenXenith> The reputation of openresty is rather irrelevant. As long as their jit fork works |
| 20:15 |
muurkha |
yeah, "bump lua version" is more like a "break everything" change |
| 20:16 |
muurkha |
it's not like bumping a Python version or a Perl version or a GCC version |
| 20:16 |
Desour |
just a recent quote from mikepall: > Stop reporting OpenResty bugs here! It's many commits behind, it |
| 20:16 |
Desour |
has lots of bad/broken patches and even broken architectures. |
| 20:16 |
MTDiscord |
<luatic> TBF I don't like the addition of integers in 5.3 |
| 20:16 |
Desour |
src: <https://www.freelists.org/post/luajit/iterate-over-nonempty-got-nothing,1> |
| 20:17 |
MTDiscord |
<GoodClover> Is the openresty JIT backwards-compatible with all the FII-dependent libraries out there? If not it's a hard no from me. |
| 20:17 |
MTDiscord |
<GreenXenith> "Many commits behind" isn't applicable, the codebase is substantially different |
| 20:17 |
Desour |
anyway, why should we increase the lua version and break all mods? |
| 20:17 |
MTDiscord |
<ROllerozxa> because change, goddamnit! |
| 20:17 |
MTDiscord |
<ROllerozxa> /s |
| 20:18 |
muurkha |
it might be nice to import some of the features from newer Lua versions |
| 20:18 |
MTDiscord |
<GreenXenith> I'd gladly sacrifice the mod ecosystem to get first class bitops |
| 20:18 |
MTDiscord |
<GreenXenith> :] |
| 20:18 |
muurkha |
I was thinking about those, yeah |
| 20:18 |
MTDiscord |
<luatic> bitops aren't nearly as useful as you make them out to be |
| 20:18 |
MTDiscord |
<GreenXenith> For you |
| 20:18 |
muurkha |
but that's not in itself a backward incompatible change |
| 20:18 |
MTDiscord |
<luatic> you can emulate 99% using floor, mod and pow, sub and div |
| 20:18 |
muurkha |
you can just use the bitops module, you don't have to do that |
| 20:19 |
MTDiscord |
<GreenXenith> They are infinitely useful in every application you haven't needed, apparently |
| 20:19 |
MTDiscord |
<luatic> and for the remaining stuff we have the bit library now which operates on 32 of the 64 double bits |
| 20:19 |
Desour |
you don't need to emulate, we have the bitop lib, luatic |
| 20:19 |
MTDiscord |
<luatic> Desour: I'm aware |
| 20:19 |
MTDiscord |
<luatic> GreenXenith: I wrote a PNG reader using my emulated bitops. It's definitely possible. |
| 20:19 |
muurkha |
for most code I'd agree that bit ops aren't very useful, but packing stuff bitwise into node params is pretty common for mods |
| 20:19 |
MTDiscord |
<GreenXenith> Possible doesn't mean good |
| 20:20 |
MTDiscord |
<luatic> muurkha: That is an example where mod, div-sub / floor work exceptionally well. |
| 20:20 |
Desour |
luajit has some extensions from newer versions, btw.: https://repo.or.cz/luajit-2.0.git/blob_plain/refs/heads/v2.1:/doc/extensions.html |
| 20:20 |
MTDiscord |
<GreenXenith> Besides, ther are plenty more features than bitops |
| 20:20 |
MTDiscord |
<GreenXenith> There* |
| 20:20 |
muurkha |
GreenXenith: what are your favorites? |
| 20:21 |
MTDiscord |
<luatic> The problem stems in part from the fact that due to double representation, bitops on a double with an uint value won't necessarily work the way you might think they work |
| 20:21 |
MTDiscord |
<luatic> but if you use emulation, everything is fine, and your hardly need more Lua VM ops |
| 20:21 |
MTDiscord |
<GreenXenith> Constants might be nice, and there's some newer table methods/metamethods that I'd like |
| 20:22 |
MTDiscord |
<luatic> Also closeables :] |
| 20:25 |
muurkha |
which metamethods? |
| 20:27 |
MTDiscord |
<GreenXenith> Can't recall at the moment |
| 20:27 |
MTDiscord |
<luatic> well, you get the entire bitops as syntactic sugar |
| 20:27 |
muurkha |
luatic: closeables are finalizers? |
| 20:27 |
MTDiscord |
<luatic> also __len works I believe? |
| 20:28 |
MTDiscord |
<luatic> muurkha: you can mark local vars as closeable / "to close" to have them be closed when they go out of scope |
| 20:28 |
muurkha |
I guess that's not quite the same thing as finalizers |
| 20:28 |
muurkha |
maybe a better alternative |
| 20:29 |
MTDiscord |
<luatic> I suppose you would call the __close handling metamethod the "finalizer"? |
| 20:30 |
muurkha |
sort of, but going out of scope isn't the same thing as being garbage collected |
| 20:30 |
MTDiscord |
<luatic> well, Lua has __gc for that |
| 20:31 |
muurkha |
oh I didn't remember that |
| 20:31 |
muurkha |
the bitop syntactic sugar can be nice for embedded DSLs. parser combinators, that kind of thing |
| 20:33 |
|
v-rob joined #minetest |
| 20:48 |
* Desour |
likes how the remover testtool in devtest looks like a cross. it makes it look like you're doing some sort of exorcism |
| 20:49 |
|
FreeFull joined #minetest |
| 21:16 |
|
Verticen joined #minetest |
| 21:45 |
|
v-rob joined #minetest |
| 22:34 |
|
panwolfram joined #minetest |
| 22:52 |
|
proller joined #minetest |
| 23:09 |
|
proller joined #minetest |
| 23:51 |
|
Lesha_Vel joined #minetest |
