Time Nick Message 07:03 repetitivestrain Krock: crash has disappeared, thanks 10:48 [MatrxMT] Please vote on what, if anything, the default inventory key should be redefined to https://forum.luanti.org/viewtopic.php?p=446934#p446934 11:21 MinetestBot 02[git] 04SmallJoker -> 03luanti-org/luanti: Mapgen: Correct border block criteria (#16524) 13dd3530d https://github.com/luanti-org/luanti/commit/dd3530dc799bff084bf8ff3ca1367d858545e7e1 (152025-09-29T11:21:30Z) 11:23 MinetestBot 02[git] 04fetsorn -> 03luanti-org/luanti: Update comments referring to obsolete TOCLIENT_INIT (#16522) 13e3ec044 https://github.com/luanti-org/luanti/commit/e3ec044ed02dbdf5fd7b92cb474f32cdcbcb9d35 (152025-09-29T11:21:52Z) 11:26 MinetestBot 02[git] 04sfan5 -> 03luanti-org/luanti: Android: Update to SDK 35 (#16513) 138f98b4f https://github.com/luanti-org/luanti/commit/8f98b4f24347e159e18513c32321b93fdbcf1bda (152025-09-29T11:25:23Z) 11:26 MinetestBot 02[git] 04Wuzzy2 -> 03luanti-org/luanti: Update builtin locale (#16512) 13274d8a7 https://github.com/luanti-org/luanti/commit/274d8a7c657a7a0bb781bcbc187098b144266c95 (152025-09-29T11:25:42Z) 11:50 erle what bug does the “Mapgen: Correct border block criteria” patch by SmallJoker address? the commit description is ass, it only claims that it addresses “a regression” 11:51 erle is it maybe #16516? 11:51 ShadowBot https://github.com/luanti-org/luanti/issues/16516 -- Suspected lighting regression 11:53 sfan5 why "maybe"? is is linked in the PR description 13:58 erle because no one thought it necessary to write it down i guess? given the amount of thought that goes into bugfixes like that i really don't understand why people like to make vague commit messages or PR descriptions like “this fixes some regression from #whatever” or “fix performance issues” or so. my personal assumption is that they do not care about maintenance and legibility the way i do and do not account for “project is moved to a differen 13:58 erle t hoster” even if it happened in the past. 13:59 erle i just wanted to check on that thing since it touches the map border and the majority of ideas people (even coredevs) have about changing what happens at the map border introduces subtle bugs. 13:59 sfan5 it does not touch the map border 14:00 erle and that's why i wanted to see which issue is fixed here. 14:00 erle i had same problem at work 14:01 erle people write commit messages like “fix bug #whatever” and then 5 years later no one knows what that even meant 14:01 [MatrxMT] most of those never have anything written under the top line either 14:01 erle but it is a decision for project maintainers to decide on commit messages hygiene and i am not one of them 14:01 erle thus, i ask. i got my answer. thanks! 14:02 erle i think cora sometimes rewrites commit messages on projects when contributors deliver the solution, but not the description. i do so myself too. 14:03 sfan5 it is pretty clear that moving the git host would include preserving the old issues and PRs for reference purposes 14:03 erle as i said before: given the amount of brain power that goes into finding solutions, idk why some people love to write vague commit messages. do you have an idea? 14:05 sfan5 time and effort 14:05 erle and by “vague” i mean “i can not know what this is about from ‘git log’” 14:05 erle yeah, but the time on the fix has been spent and the effort to understand the issue also 14:05 erle is it simply difficult for people to put it into words maybe? 14:06 sfan5 what I was trying to say is that it is additional time and effort that people don't want to spend 14:07 erle well, the time and effort needs to be spent everywhere the stuff is read then i guess. and commit messages are more often read than wrote. 14:07 erle a tradeoff, i guess. one i do not condone, but others do. 14:07 luatic It is completely acceptable when a commit references a discussion in an issue tracker that has all the relevant details. 14:08 erle luatic as i said: “others do” 14:08 luatic I'm not convinced that commit details are read often enough for that indirection to be a problem 14:09 [MatrxMT] maybe my workflow isn't very good, but my main way of inspecting history is grepping the output of git log and reading the commit messages in full 14:09 erle for me too 14:09 [MatrxMT] there's a reason github autofills the PR form with commit message contents 14:09 erle luatic, you are seeing the same tradeoff and simply saying it is a problem for future devs when the issue comes up, not present devs when the issue is at hand. 14:10 erle what i see though is context loss. future work is rare, but a lot harder. because it is not done by the person who fixes the issue at present time. 14:10 erle so you see “Fix crash” and then have to dig. if you are lucky you have an issue tracker! 14:12 erle luatic i have seen the tradeoff go both ways btw, mostly in relation to “can we use git bisect and expect success figuring out the issue with that alone?” 14:13 repetitivestrain erle: it's #16516 14:13 ShadowBot https://github.com/luanti-org/luanti/issues/16516 -- Suspected lighting regression 14:13 erle at my previous workplace i noticed that embedded developers would have very good commit hygiene. small commits, good descriptions of what was fixed. mobile developers had not. 14:14 erle it turned out that those developers who believed that it would help them with debugging issues later would do small commits and clear descriptions and those who believed it would not, would do giant commits and have poor descriptions. 14:14 erle both were a self-fulfilling prophecy 14:15 erle but one of the mobile developers ultimately explained to me why they chose that side and not the others: there was so much code churn, imposed by others (like new version of some vendor library breaking things), that they rarely even had bugs where git bisect and reading commit messages would help. 14:16 erle IIRC it did convince many on one side though that git bisect was useful in every case and many on the other that git bisect was useless in every case. 14:16 erle funny 14:18 erle of course i guess most of you were never asked to fix a legacy project with commit messages like “fuck yeah it works now” 14:45 crazylad hi 14:45 crazylad wait- wrong one 14:56 mrcheese crazylad: ... 14:59 crazylad I really like the idea proposed in issue #16528 - in fact, I've made a small mod as a workaround that adds a /first-login command 14:59 ShadowBot https://github.com/luanti-org/luanti/issues/16528 -- Expose player creation_date to Lua; /first-login 15:02 crazylad I made a small Python script to read players' names and their creation_dates and organize them in a JSON file - however this adds alot of overhead probably for servers with a large playerbase 15:03 erle crazylad how do you know the player creation date is indeed the first login though? 15:03 erle crazylad players might be “created”, but not fully provisioned. 15:04 crazylad oh interesting - I haven't used it in a server, just my singleplayer testing, but it's a nice concept 15:04 mrcheese :P 17:53 MinetestBot 02[git] 04SmallJoker -> 03luanti-org/luanti: Server: Fix Server::Send exception caused by leaving players 13499f228 https://github.com/luanti-org/luanti/commit/499f2284bdfb702f68d200dc792720e4047da8e2 (152025-09-29T17:23:43Z) 18:26 Krock Lua trivia: instead of separating table fields with a comma, you may also use a semicolon 18:51 * SwissalpS wonders how that was thought of as a useful feature 18:53 SwissalpS having single and double quotes interchangeable (in pairs) makes a lot more sense to me 18:57 erle makes little sense to me. i use the rc shell, which has only one way of quoting things. 18:58 SwissalpS local s1 = "I can't do that"; local s2 = 'He said: "I can do that" and then he left' 18:59 SwissalpS no escaping needed 19:13 erle SwissalpS if you have one single quote, the escape rule can simply be: “if you want to have the quoted character inside a string, double it” 19:13 erle (this is how it is in rc shell) 19:14 erle parsing is way easier that way for both humans and computers, you *always* look for a single quote to start/end a quoted context 19:14 erle with multiple ways to quote, you need to remember which type of quote at the very least 19:16 identity but then to have a string with three single quote characters you would do '''''''' which is, uh 19:16 identity to be fair, it is a fairly contrived example 19:17 identity a fairly fair contrived example… 19:18 erle identity you can of course make the quoting rule something else. but that means you need to match more than one character. 19:18 SwissalpS yeah, I grant you that parsing is simpler 19:18 erle i have an attention deficit. holding more context in my head is much more straining than for normies. 19:18 erle so i recognize “easier parsing” much more, because it is less straining 19:20 erle given that inside a quoted context you only need to divide the amount of quotes by 2, the “contrived example” is very easy to read. you have a single quote at the start, a single quote at the end, divide the escaped single quotes in the middle by two. 19:21 erle usually it will be more like s1='I can''t do that' though 19:21 identity it looks really wrong with proportional fonts, though… 19:21 erle yeah, it's *ugly* 19:22 erle but then, stuff like -> in C++ instead of → is ugly too and people use that all the time 19:22 erle or ** instead of ^ in python 19:22 erle i'd rather see x² in source code than x**2 but who am i to have an opinion … 19:26 erle identity same thing with postfix notation btw, less things to keep in mind. 2 + 2 requires more context than 2 2 + 19:26 erle calculations i often do in dc(1) for that reason 19:31 identity PEMDAS is hell, i do most of my programming in languages that would express 2 + 3² without the need for operator precedence, either as (+ 2 (expt 3 2)) for Lisps or 2+3⋆2 for APL&co. (which are usually right-to-left) 19:32 identity every time i read “learn operator precedence, do not overuse parentheses” in style guides for c-like languages i groan