Time Nick Message 12:41 kilbith this commit causes a regression with the sound in formspecs: https://github.com/minetest/minetest/commit/e51f47461 12:42 kilbith I cannot hear the click sound on i3 anymore (buttons use the `sound` property in StyleSpec) 12:42 kilbith ^ Krock 12:46 MTDiscord kilbith: Open an issue. 13:23 Krock hmm 13:25 Krock I see. it's an awful implicit type conversion 13:26 Krock C++ likes to cast "false" to 1.0f 13:26 Krock * 0.0f but you get th idea 13:35 Krock kilbith: please confirm whether this completely restores the previous behaviour: https://krock-works.uk.to/u/patches/0001-GUIFormSpecMenu-Fix-parameter-order.patch 13:35 Krock I tested it locally and it works well from what I can tell 13:38 kilbith Krock: seems to work 13:38 Krock thanks. will push in 15 minutes 13:53 Krock pushing 14:11 rubenwardy Krock: Minetest's GUISkin class is needed to support formspec styling 14:11 rubenwardy it could be upstreamed into irr-mt though 14:16 kilbith > CDB has 1488 packages, with a total of 6000872 downloads. 14:16 kilbith 6M reached 14:17 MTDiscord ? 14:21 sfan5 rubenwardy: other way around rather 14:31 Krock remove CGUISkin from Irrlicht 15:21 kilbith http://codepad.org/RgfDjFKE 15:22 kilbith I'm not receiving anything from GenericCAO, I am missing something? 15:22 kilbith network really isn't my thing 15:43 kilbith yeah I miss sending a packet from UnitSAO 15:56 kilbith UnitSAO::attachCamera (ID): 1 15:56 kilbith got it 16:16 fluxionary a couple days ago, someone suggested building minetest with "sanitizers", so i built a client w/ memory sanitizers, and it found some (not huge) memory leaks in irrlicht. is anyone actually interested in that output? 16:21 fluxionary er, "address" sanitizers 18:03 erle fluxionary was it me? ;) 18:04 erle fluxionary i suggest to open issues on the bug tracker, but look before if there are already ones. if it applies to upstream irrlicht, open issues there as well. 18:10 fluxionary alright, created https://github.com/minetest/irrlicht/issues/121. 18:11 fluxionary running w/ memory sanitizers might be more productive (and compiling luajit w/ those too), though i'll have to figure out how to get things to recognize clang (gcc doesn't support that) 18:26 Krock at least valgrind gets a bit confused about LuaJIT sometimes 18:27 Krock I did the memory sanitizer thing for Minetest a while ago. there's indeed a few minor issues, but generally not too concerning 18:49 schwarzwald[m] fluxionary: `CMAKE_CXX_COMPILER=clang CMAKE_C_COMPILER=clang` environment variables do the trick IIRC. Been a little while since I did it though. 18:52 schwarzwald[m] Requires clean build directory to set compilers (can't change it for existing build) so out of source build is probably a good idea. 18:52 fluxionary ah nice, i noticed `CC=clang;CXX=clang++` didn't work and went back to doing other things 18:53 sfan5 $CC and $CXX do work, trying to set CMAKE_ stuff via environment might not 18:53 fluxionary gotta reboot, back in a moment (hopefully) 18:57 sfan5 most of that log (where it says "Indirect leak" I guess) is probably stuff that just happens to be around at shutdown and wasn't deleted but could still be 18:57 fluxionary aha. what about the direct leak stuff? 18:58 sfan5 that probably a problem 18:59 sfan5 +'s 19:00 fluxionary fortunately none of the leaks seemed very big, though it'd be interesting to see what happens on a busy server 19:02 fluxionary (which obviously wouldn't have irrlicht stuff going on) 19:08 fluxionary `CMAKE_CXX_COMPILER=clang` (and C) worked when passed as an a `-D` argument to cmake, though the build failed w/ a linker error... hm. 19:13 sfan5 it's clang++ 19:23 fluxionary either one works i think 19:24 fluxionary in any event, it looks like using memory sanitizers requires building custom versions of the standard libraries... 19:24 sfan5 clang will "works" but miss libstdc++ in the linking step 19:25 sfan5 hence clang++, which is meant to compile c++ 19:27 fluxionary oh, that was my linking issue 19:27 fluxionary in any event, i've got more work to do if i want to try this feature 20:22 fluxionary gave up on that for now, maybe i'll try it another day 21:57 kilbith Some exception: "vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)" 21:57 kilbith does it make any sense? 21:58 kilbith it throws an exception on .at(i) 22:08 schwarzwald[m] kilbith: Indexing the vector out of bounds, but maybe you were asking in a more specific context. 22:09 kilbith I can understand the > part which is indeed out of bound but what about the = ? 22:12 schwarzwald[m] >= because at(size()) would be out of bounds. 22:13 schwarzwald[m] Size 0 means so elements so index 0 is >= size and therefore out of bounds. 22:13 schwarzwald[m] s/so/no/ 22:14 schwarzwald[m] Sorry, I forgot editing a message sends a new copy to IRCE 22:14 kilbith oh I thought that vector.size() == 0 when it was filled with one element 22:15 kilbith got confused vector.at(0) accessing the first element 22:42 erle kilbith oh, are there any languages where that is indeed the case that you always have to remove 1 to know the size? 23:31 rubenwardy MacOS bugs: https://appdot.net/@mdhughes/108624993095436787 23:33 rubenwardy do any core devs have a mac? 23:40 MTDiscord dead link btw 23:40 rubenwardy works for me 23:41 MTDiscord maybe you need to be signed in? 23:41 rubenwardy I'm not signed in 23:41 MTDiscord odd 23:42 rubenwardy https://rwdy.uk/hM1R1.png 23:56 MTDiscord I've had those Mac input lag problems before. What I observed wasn't a fixed lag kind of thing, it felt more like inputs were being buffered faster than they could be processed, so if I held the dig button down longer, it would keep swinging longer after I tried to stop. 23:58 MTDiscord I actually got used to ending a dig by pointing off somewhere that wouldn't cause damage while I waited for the tool to calm itself back down. I just assumed it was part of the "nobody really cares about Mac" problem.