| 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 |
