Time  Nick           Message
02:19 cfnblx         https://github.com/minetest/minetest/issues/13267
10:26 MTDiscord      <kimapr> #13268
10:26 ShadowBot      https://github.com/minetest/minetest/issues/13268 -- Form with malformed png texmod segfaults the client
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
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: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
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
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: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: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: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.