Minetest logo

IRC log for #minetest-dev, 2023-03-02

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:22 Baytuch joined #minetest-dev
01:28 Baytuch joined #minetest-dev
01:52 kilbith_ joined #minetest-dev
02:19 cfnblx https://github.com/minetest/minetest/issues/13267
02:27 Baytuch joined #minetest-dev
05:00 MTDiscord joined #minetest-dev
05:53 calcul0n joined #minetest-dev
06:04 Baytuch joined #minetest-dev
06:41 YuGiOhJCJ joined #minetest-dev
08:38 appguru joined #minetest-dev
09:46 Baytuch joined #minetest-dev
09:50 Baytuch joined #minetest-dev
10:26 MTDiscord <kimapr> #13268
10:26 ShadowBot https://github.com/minetest/minetest/issues/13268 -- Form with malformed png texmod segfaults the client
10:38 Baytuch joined #minetest-dev
12:36 appguru joined #minetest-dev
12:53 sfan5 reminder that the android build currently doesn't work because approved #13245
12:53 ShadowBot https://github.com/minetest/minetest/issues/13245 -- [no squash] Fix task ordering and more in Gradle Android build by sfan5
12:53 sfan5 +nobody
13:00 Baytuch joined #minetest-dev
13:16 kilbith joined #minetest-dev
13:36 Baytuch joined #minetest-dev
13:45 Baytuch joined #minetest-dev
13:52 kilbith_ joined #minetest-dev
14:26 proller joined #minetest-dev
14:52 kilbith do we *really* need to support every DB under the sky?
14:56 celeron55 i don't think mariadb is needed. the maintenance burden shouldn't fall on the core team at least
14:57 kilbith then we agree
14:58 celeron55 nrz_: what do you think about long term support?
14:59 celeron55 it's fun to merge a contribution like that, but it can never be removed and will always have to be maintained
15:00 proller why there still no clickhouse support?
15:00 kilbith because it's russian and we don't like russians
15:02 proller they more than year in netherlands
15:02 Baytuch_2 joined #minetest-dev
15:03 MTDiscord <kimapr> we don't like russians?
15:14 lebruhgamer[m] <kilbith> "because it's russian and we don..." <- wow, why am I not surprised at all that someone who's discriminating against poor people and want to remove support for old hardware support, is ALSO someone who is a russophobic -- at this point I'm not even surprised if this person is also <insert religion>-phobic as well and only view their own view as the most important one, ie, selfish egoist .. possibly narcissist
15:20 MTDiscord <ROllerozxa> geez kilbith
15:20 MTDiscord <Warr1024> "shouldn't fall on the core team at least" ... sounds like a good case for pluggable database backends.  Would be pretty nice to be able to install those from CDB, for sure...
15:21 kilbith those who boo are necessarily on the sidelines and not in the arena anyway
15:22 proller why russian servers still not removed from serverlist?
15:23 rubenwardy I don't think Putin has a Minetest server
15:24 lebruhgamer[m] why are we discriminating russian to begin with? they don't even choose to be born there and whatever their government is doing is separate from the actual people
15:24 kilbith my ass
15:24 MTDiscord <Warr1024> The opinions of kilbith do not represent the opinions of the Minetest Core Dev team.
15:25 kilbith it's the common speech from the russian people but I don't want to elaborate
15:25 proller but everyone who has servers pays taxes to Putin
15:26 pgimeno last time I looked this was a minetest development channel
15:27 lebruhgamer[m] go watch NFKRZ or something to see Russian who are against Russian government, a lot of them got jailed but they exist and always on the run to continue protesting while avoiding jail
15:28 lebruhgamer[m] trying to paint the whole Russia in over-generalization is a bad thing
15:30 kilbith if you're offered a basket of 100 strawberries but are told 10 are deadly, you're not gonna accept to put your hands in it
15:31 lebruhgamer[m] like USA is known to be a very bad country for example, for having school shooting every day, but people don't over-generalize the whole country that people need to avoid living there
15:32 Warr1024 I don't know if this is too off-topic for #minetest, but it's definitely too off-topic for #minetest-dev
15:32 pgimeno +1
15:43 MTDiscord <luatic> +42
16:59 appguru joined #minetest-dev
17:09 Baytuch joined #minetest-dev
17:20 nrz_ celeron55, hmm i don't think we will change db scheme often now, and it's mariadb, a long known db with pretty standard sql
17:21 nrz_ I reviewed code quality only. For long term, it's just project goals. For me pg is stronger
17:25 nrz_ I may have an idea for such support, maybe plugable lib permit ting people to implement it ? Wdyt
17:26 nrz_ In mangos emu we had such thing for IA implémentations, and we kept only a stub library as example bindings in the project
17:37 Baytuch joined #minetest-dev
17:38 LandarVargan joined #minetest-dev
18:01 Zughy[m] It's fun, nrz_ pops up out of nowhere saying that they support MariaDB and at the same time celeron55 pops out saying the opposite. What exactly should I do?
18:01 Zughy[m] With the PR I mean
18:02 Zughy[m] *pops up saying
18:02 Baytuch joined #minetest-dev
18:04 celeron55 i won't be mad if you ignore me
18:04 celeron55 it's just that i also won't be the one who maintains mariadb support 8)
18:10 Zughy[m] Well, with this reasoning, considering how much nrz_ disappears, it's risky having them taking such responsibility
18:16 MTDiscord <Jonathon> adding mariadb cant be any worse than having a leveldb (map) backend that randomly corrupts itself
18:27 Krock will merge #13242 and #13245 in 15 minutes (2nd one LGTM)
18:27 ShadowBot https://github.com/minetest/minetest/issues/13242 -- Enable connected glass by default by PrairieAstronomer
18:27 ShadowBot https://github.com/minetest/minetest/issues/13245 -- [no squash] Fix task ordering and more in Gradle Android build by sfan5
18:43 rubenwardy in theory, leveldb is the superior map backend for a voxel world
18:43 rubenwardy in practice...
18:56 proller how to corrupt leveldb without power loss or kill-9 ?
18:56 Krock merging...
18:57 Krock done
19:10 proller leveldb can be repaired with this - https://github.com/proller/leveldb/blob/repair2/db/leveldbrestore.cc
19:21 Arekusei joined #minetest-dev
19:23 MTDiscord <Arekusei> didn't know irc channels could get so political, kinda regret hiding the channels :^)
19:25 Arekusei does this irc channel have history view?
19:27 Krock Arekusei: https://irc.minetest.net/minetest-dev/
19:27 Arekusei thanks
19:30 MTDiscord <luatic> Yes, you interpreted the trollface correctly; the trollface meant my message was to be interpreted semi-serious
19:31 MTDiscord <luatic> lol, I'm not your boss, and I'm pretty much fresh out of highschool (I did some Uni during highschool though)
19:32 MTDiscord <caffeinatedblocks> I was just being snarky
19:32 MTDiscord <luatic> hehe
19:35 rubenwardy IRC can't see reply contexts
19:35 rubenwardy so it looks like luatic is talking to himself
19:36 Pexin eye do zat zometimez..
19:36 cfnblx I'm on IRC and I see <+MTDiscord><luatic> Yes, you....
19:36 cfnblx <+MTDiscord><caffeinatedblocks> I was just...
19:37 MTDiscord <luatic> Yeah, should've mentioned that I was replying to Krock's "I think that comment [...] was not meant serious" and your "when your boss is fresh out of college [...]"
20:17 cfnblx https://github.com/minetest/minetest/pull/13266
20:18 cfnblx regarding nerzhul's requested changes...
20:18 cfnblx 1) you can optimize a bit the code by not putting a ; on each line ending and calling oss only on first line
20:19 cfnblx I actually modeled this after how I saw you guys doing it elsewhere in the engine code. I originally had it the way it is now suggested, but modified it to better "fit in". Which is the preferred method?
20:23 rubenwardy the engine isn't always the best guide
20:35 pgimeno nrz_: > just SELECT name, not all fields, this will optimize fetch time DB side   <--   the standard definition for EXISTS specified to always use SELECT * for a while (not sure if it's still the case). For this reason it's basically guaranteed to be optimized. But you're right on "never use SELECT * for returning".
20:36 pgimeno for returning the fields, that is
20:41 cfnblx I'm working on additional optimizations right now
20:41 cfnblx rubenwardy: // player/name below is set to VARCHAR(20) as per rubenwardy pointing out that player.h defines: PLAYERNAME_SIZE 20 so it should never exceed this anyway.
20:42 cfnblx would it be appropriate to place a comment like this in the comments surrounding that table definition?
20:42 cfnblx or should I just notate that in the PR comments?
20:42 rubenwardy I don't think it's needed. If MySQL silently truncates the text (which would be crazy), then I'd add a C++ assertion
20:43 MTDiscord <luatic> I think it would be cleanest to import the constant from player.h
20:43 cfnblx how do i do that?
20:43 cfnblx just #include <player.h> and reference that value?
20:43 MTDiscord <luatic> yes
20:44 MTDiscord <luatic> not sure whether it'd be cleaner to string concat / macro in the 20 vs. parameterizing the query
20:44 cfnblx and considering it's a string, can I just "name varchar(" + PLAYERNAME_SIZE + "), "; ?
20:44 rubenwardy it's a constant, you don't need the +
20:44 cfnblx I think concat is cleaner personally
20:44 rubenwardy oh wait it's a number
20:45 cfnblx ... + std::string(PLAYERNAME_SIZE) + ... then?
20:45 cfnblx or would it be better as a cast ... + (std::string)PLAYERNAME_SIZE + ... ?
20:46 MTDiscord <luatic> I don't think you can just cast a number to string...
20:46 rubenwardy std::to_string
20:46 MTDiscord <luatic> ^
20:46 rubenwardy was hoping for a macro way to do it so you can just preprocess join the strings
20:46 MTDiscord <luatic> yeah
20:47 MTDiscord <caffeinatedblocks> https://cdn.discordapp.com/attachments/747163566800633906/1080954602666610859/Screen_Shot_2023-03-02_at_3.47.21_PM.png
20:47 MTDiscord <caffeinatedblocks> I think this looks pretty clean this way, and makes it easier to modify later if needed for tweaks/customization
20:48 cfnblx thoughts now that you have eyes on it?
20:51 MTDiscord <x2048> rubenwardy: #define STR_VALUE(x) #x
20:51 MTDiscord <x2048> "..." STR_VALUE(PLAYERNAME_SIZE) "..."
20:51 MTDiscord <luatic> yeah, that should work
20:51 MTDiscord <luatic> but I don't really think it's cleaner
20:53 MTDiscord <caffeinatedblocks> Do you literally mean to use x?
20:54 MTDiscord <luatic> #x stringizes x
20:54 MTDiscord <luatic> so this macro will expand to "20", which will then be concatenated with the nearby strings 🪄
20:54 MTDiscord <caffeinatedblocks> https://cdn.discordapp.com/attachments/747163566800633906/1080956428744925244/Screen_Shot_2023-03-02_at_3.54.46_PM.png
20:55 MTDiscord <luatic> still I think the std::to_string variant, albeit negligibly less efficient, is more readable
20:55 MTDiscord <luatic> I wouldn't premature-optimize this.
20:55 MTDiscord <caffeinatedblocks> https://cdn.discordapp.com/attachments/747163566800633906/1080956558684459128/Screen_Shot_2023-03-02_at_3.55.18_PM.png
20:55 MTDiscord <caffeinatedblocks> like that?
20:56 MTDiscord <luatic> yeah
20:57 MTDiscord <caffeinatedblocks> I don't think that's less readable than std::tostring
20:58 MTDiscord <x2048> STR_VALUE is something I took from SO, feel free to choose a better name 😄
20:58 MTDiscord <caffeinatedblocks> I think it's quite fitting
21:00 MTDiscord <x2048> FYI config.h defines STR(x) and STRINGIFY(x)
21:01 MTDiscord <x2048> util/string.h defines STRINGIFY(x) and TOSTRING(x)
21:03 MTDiscord <caffeinatedblocks> oh so I can just use those because I already include config.h
21:03 MTDiscord <caffeinatedblocks> Which would be best to use?
21:03 MTDiscord <caffeinatedblocks> (which one is lease likely to go away in the future)?
21:04 MTDiscord <x2048> no difference. Any change to macros is a search and replace on the codebase for the future generations.
21:04 MTDiscord <luatic> so we have 3 stringify macros?
21:04 MTDiscord <x2048> yes
21:04 MTDiscord <x2048> 4
21:04 MTDiscord <luatic> :minetest: moment
21:05 MTDiscord <luatic> (and to some extent C moment)
21:05 nrz_ Mysql silent truncate, who does show warnings after a query ? No one.
21:06 nrz_ Zughy, I don't say I support, I said I reviewed and if you Think it's useful you have my suggestions
21:06 nrz_ For select * in query with row fetch, there is no guarantee of column ordering if db has been populated or modified
21:07 nrz_ Ie alter table, Or db restore
21:08 MTDiscord <caffeinatedblocks> Fun fact: Postgre indexes player_metadata on (name, attr) but all queries for player_metadata only consist of WHERE player = $1
21:08 nrz_ I know I disapear often, but I'm reading all messages here :p, but not all pr on GitHub, I admit
21:09 MTDiscord <caffeinatedblocks> I made the mistake of looking at postgre's definitions, so my tables wound up equally screwed up as a result.
21:09 MTDiscord <caffeinatedblocks> I'll fix that and include that in a separate commit
21:28 pgimeno <luatic> so this macro will expand to "20", which will then be concatenated with the nearby strings 🪄  <-- incorrect, it will expand to "PLAYERNAME_SIZE". You need one indirection if you want it to do the right thing (expand the PLAYERNAME_SIZE macro).
21:30 pgimeno (I'm talking about #define STR_VALUE(x) #x )
21:31 Baytuch joined #minetest-dev
21:37 Baytuch joined #minetest-dev
21:38 MTDiscord <paradust> caffeinatedblocks: By name you mean player? What is the significance of this
22:12 MTDiscord <caffeinatedblocks> https://github.com/minetest/minetest/pull/13266
22:13 MTDiscord <caffeinatedblocks> All comments have been replied to, all errors corrected, and all suggestions accounted for
22:14 MTDiscord <caffeinatedblocks> huh?
22:17 MTDiscord <caffeinatedblocks> paradust: oh, just that postgre uses primary key (name, attr), however all queries are only on name, which itself is not indexed alone
22:17 MTDiscord <caffeinatedblocks> https://cdn.discordapp.com/attachments/747163566800633906/1080977132215349368/Screen_Shot_2023-03-02_at_5.17.03_PM.png
22:17 MTDiscord <caffeinatedblocks> In mine, I created a separate index for player only to optimize those queries
22:25 MTDiscord <Warr1024> Some meta probably query attribute-at-a-time (like mod storage) and some probably do it all at once (like player); it would be nice if we had more consistent access patterns, though that's probably more of a long-horizon kind of thing.
22:32 MTDiscord <caffeinatedblocks> Are you ever going to accept my friend request
22:32 MTDiscord <Warr1024> It disappearded.  Also probably better to move Discord-related talk to a not-IRC channel.
22:50 MTDiscord <paradust> caffeinatedblocks: Why does that matter? An index on (X,Y) will work fine for lookups on X alone (but not Y)
22:50 MTDiscord <paradust> assuming a tree index, which the primary key is
23:03 MTDiscord <Warr1024> It's not like a mortal sin or something, it's just a little wasteful.
23:36 Baytuch joined #minetest-dev
23:59 Desour joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext