| Time |
Nick |
Message |
| 00:18 |
|
behalebabo joined #minetest-dev |
| 00:28 |
|
kilbith joined #minetest-dev |
| 01:09 |
|
independent56 joined #minetest-dev |
| 01:28 |
|
independent56 joined #minetest-dev |
| 01:32 |
|
independent56 joined #minetest-dev |
| 01:34 |
|
independent56 joined #minetest-dev |
| 01:36 |
|
independent56 joined #minetest-dev |
| 03:18 |
|
olliy joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:28 |
|
Yad joined #minetest-dev |
| 05:55 |
|
calcul0n_ joined #minetest-dev |
| 09:04 |
|
Warr1024 joined #minetest-dev |
| 09:10 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:25 |
|
Fixer joined #minetest-dev |
| 09:26 |
|
independent56 joined #minetest-dev |
| 10:11 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:15 |
|
HuguesRoss joined #minetest-dev |
| 10:51 |
|
Yad joined #minetest-dev |
| 10:56 |
|
appguru joined #minetest-dev |
| 11:10 |
|
independent56 joined #minetest-dev |
| 11:19 |
|
Yad joined #minetest-dev |
| 11:57 |
|
Taoki joined #minetest-dev |
| 11:58 |
|
Yad joined #minetest-dev |
| 12:27 |
|
Warr1024 joined #minetest-dev |
| 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 |
<luatic> 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 |
<luatic> ? |
| 14:21 |
sfan5 |
rubenwardy: other way around rather |
| 14:31 |
Krock |
remove CGUISkin from Irrlicht |
| 14:49 |
|
HuguesRoss joined #minetest-dev |
| 15:00 |
|
HuguesRoss joined #minetest-dev |
| 15:00 |
|
Yad joined #minetest-dev |
| 15:07 |
|
HuguesRoss8 joined #minetest-dev |
| 15:12 |
|
HuguesRoss3 joined #minetest-dev |
| 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:31 |
|
Yad joined #minetest-dev |
| 15:43 |
kilbith |
yeah I miss sending a packet from UnitSAO |
| 15:45 |
|
Yad joined #minetest-dev |
| 15:47 |
|
Yad joined #minetest-dev |
| 15:50 |
|
Yad joined #minetest-dev |
| 15:55 |
|
fluxionary joined #minetest-dev |
| 15:56 |
kilbith |
UnitSAO::attachCamera (ID): 1 |
| 15:56 |
kilbith |
got it |
| 16:11 |
|
olliy1or joined #minetest-dev |
| 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 |
| 17:32 |
|
olliy joined #minetest-dev |
| 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 |
|
Warr1024 joined #minetest-dev |
| 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 |
|
independent56 joined #minetest-dev |
| 18:53 |
fluxionary |
gotta reboot, back in a moment (hopefully) |
| 18:55 |
|
fluxionary joined #minetest-dev |
| 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:21 |
|
independent56 joined #minetest-dev |
| 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:12 |
|
Baytuch joined #minetest-dev |
| 20:22 |
fluxionary |
gave up on that for now, maybe i'll try it another day |
| 20:57 |
|
erle joined #minetest-dev |
| 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:34 |
|
panwolfram joined #minetest-dev |
| 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 |
<Jonathon> dead link btw |
| 23:40 |
rubenwardy |
works for me |
| 23:41 |
MTDiscord |
<Jonathon> maybe you need to be signed in? |
| 23:41 |
rubenwardy |
I'm not signed in |
| 23:41 |
MTDiscord |
<Jonathon> odd |
| 23:42 |
rubenwardy |
https://rwdy.uk/hM1R1.png |
| 23:56 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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. |
