Time Nick Message 01:17 v-rob How does one push a small bugfix patch to GitHub without making a PR? 01:23 v-rob Do I just push a commit directly to master after notifying here? 01:25 MTDiscord > If you have a small patch, fixing some compiler error or other trivial mistake, notify about fixing it on #minetest-dev, wait for 5...15 minutes and push it. To save time, you should notify when finding the problem, not when having it fixed. If someone asks something about it, delay pushing and link the patch [4] or tell whatever else people want to know. https://dev.minetest.net/Git_Guidelines 01:26 v-rob Yeah, does that just mean pushing to master? 01:26 v-rob I assume that it does, but I'd rather not do it wrong 01:29 v-rob In any case, this is the patch: https://github.com/minetest/minetest/pull/11821#issuecomment-1005299243 01:51 v-rob Pushed 18:28 x2048 celeron55, there's been a discussion recently about me joining the core team. Is there anything needed from my side? 18:29 celeron55 x2048: mostly the answer to the questions: 1) would you like to join?, and 2) do you feel you'd have time for looking through a few PRs from others? 18:38 x2048 celeron55, 1) yes, no problem with that, 2) I spend a few hours a week on minetest, I could use some of that time to review the PRs 18:47 celeron55 i'll add you to the team on github, the rules to follow for the new permissions you'll have are here. yes they're kind of convoluted and all over the place, don't stress too much about it: https://dev.minetest.net/All_rules_regarding_to_development 18:52 x2048 Thank you! I'll read through the rules (Looks like I've seem much of it already :) ) 18:53 celeron55 regarding to how much time to spend on reviewing and coding, i don't really know. but helping review PRs will certainly make a lot of people happy 18:54 x2048 Yes, I know that first-hand :D 18:55 x2048 Have to run now, thank you for taking the time to look at it. 18:56 celeron55 i feel the core dev rules really should fit onto one simple page... 18:57 celeron55 https://dev.minetest.net/Merging_core_pull_requests_to_upstream 18:57 celeron55 this seems to be the only page that really matters 18:59 celeron55 i'll have to see if i could shorten and combine it better 19:01 erlehmann it does not seem too convoluted to me though, compared to some PRs ;) 19:03 celeron55 well... yes, PRs can be absolute nightmares 19:03 erlehmann celeron55 some projects put “what needs to be checked for this PR” into a PR template, that could externalize some of the things (i.e. the submitter would be acutely aware of it) 19:03 erlehmann i mean you already have a template 19:03 erlehmann but maybe you can save work for core devs that way 19:03 erlehmann no idea really 19:03 celeron55 the biggest part usually is reading through the actual code making sure there's nothing silly in it 19:03 celeron55 for a big PR 19:04 erlehmann i absolutely hate big PRs 19:04 celeron55 if not for any other reason than it can only be done by a few people because others just don't have the competence 19:04 celeron55 testing as well as checking the overall goal can be done by many more 19:04 erlehmann and i doubt anyone really likes them 19:09 celeron55 the review process is really about forming trust for the changes made. somebody who the community trusts has to have agreed it will move the project forward, read through the code and tested that it works. the PR author can't really do it, because they can be a complete stranger 19:12 celeron55 all they can do is make it as easy as possible to do those 3 things 19:12 celeron55 we don't quite have this type of motivation written anywhere either 19:12 celeron55 maybe it could help people be efficient 19:36 MTDiscord Was Minetest's text wrapping always this messed up? I can't fully read my error message right now because the path is too long. 19:36 rubenwardy yeah 19:36 rubenwardy there are a tonne of different wrapping implementations 19:37 rubenwardy most are a copy of a broken implementation from Irrlicht 19:37 rubenwardy one is a monospace wrapper in Lua 19:55 Pexin PR authors can't be trusted to review own work because tunnel vision haha 19:57 erlehmann that is true 19:57 erlehmann also, a reviewer is an adversary 19:58 erlehmann try to find the best reasons why the thing is bad – if you try and fail at that, it might be good! 20:10 rubenwardy a reviewer is a friend 20:11 erlehmann a yes-man is a bad reviewer and a bad-friend though 20:11 erlehmann i see it like when a friend asks me “do i look fat in this dress” 20:12 erlehmann of course i answer truthfully, even if they do – because otherwise they go out with it and may look that way to many more people 20:19 celeron55 Pexin: tunnel vision is why core dev's PRs need to be reviewed by another core dev 20:43 sfan5 celeron55: I'd consider https://dev.minetest.net/Git_Guidelines equally important to that page you linked 21:46 MTDiscord How can I determine whether CImage::copyToScaling is invoked anywhere? I can't run cachegrind past starting the main menu, with the default configuration. 21:46 MTDiscord I want to refactor the function as a personal exercise, and to follow "safety first" I need to have at least some way to make sure I don't inadvertently break something. 21:56 sfan5 add a printf and see? 21:56 sfan5 if you want a place where it's invoked for sure you can grep for one 21:57 erlehmann is “use a debugger and set a breakpoint” an option josiah_wi? 21:57 celeron55 if you have a debug build of irrlicht you could just set a breakpoint in gdb 21:57 MTDiscord I'm not familiar with using gdb, so printf should suffice for this. 21:58 erlehmann the thing is, if you have gdb you can trace the process and use the reverse execution thing 21:58 erlehmann https://getdocs.org/Gdb/docs/latest/gdb/Reverse-Execution 21:59 celeron55 well you don't need more than printf to see it's being run 21:59 celeron55 actually, you don't even need printf 21:59 erlehmann i guess i assumed the question was “from where is it run” 21:59 celeron55 abort() will make it even more clear 8) 21:59 MTDiscord I googled pitch, and it says that it is the pixel density. Pixel pitch is the distance between the centers of adjacent pixels. 22:00 MTDiscord I'm a little confused with this code, because if pitch is 0 it defaults it to the width times the bytes per pixel in the color format. 22:00 MTDiscord And of course this is not documented. 22:01 sfan5 the fallback value should tell you a lot 22:01 sfan5 you can deduce that pitch = number of bytes between a pixel and the pixel immediately below it 22:01 sfan5 other called `linesize` in other places (e.g. ffmpeg) 22:02 celeron55 it's basically just a way to align rows of pixels in a certain way in memory, basically adding empty space after each row 22:02 sfan5 this variable exists because images may be padded which would mean pitch != width*bpp/8 22:02 celeron55 some graphics hardware might require it 22:03 MTDiscord So the term is used incorrectly. ? 22:03 sfan5 terms can have multiple meanings 22:03 celeron55 pitch means exactly that when talking about storing pixels in memory 22:03 celeron55 for example SDL uses the same term 22:03 sfan5 pitch can also be used to crop horizontally crop pictures without changing a single byte in memory 22:03 sfan5 same with flipping if you make the pitch negative 22:03 sfan5 crop pictures horizontally* 22:04 MTDiscord khronos.org says that pitch is usually interchangeable with stride, but stride is more specific. 22:51 MTDiscord @josiah_wi Simple search on github gives some pointers: https://github.com/minetest/minetest/search?q=copyToScaling. 22:51 MTDiscord Local grep gives more results in https://github.com/minetest/minetest/blob/master/src/client/tile.cpp