Minetest logo

IRC log for #minetest-dev, 2015-03-23

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:44 devmarth joined #minetest-dev
00:48 Warr1024 VanessaE: in case you're interested, #2536 is now a thing.
00:48 ShadowBot https://github.com/minetest/minetest/issues/2536 -- Anti-alias all 2D GUI Elements. by Warr1024
00:48 Warr1024 also, my PR number is 2 consecutive 2-digit perfect squares
00:53 VanessaE joined #minetest-dev
01:40 VanessaE joined #minetest-dev
01:45 * est31 got #2500
01:45 ShadowBot https://github.com/minetest/minetest/issues/2500 -- on_enter_node() and register_on_enter_node() methods
01:46 est31 or no, sorry #2400
01:46 ShadowBot https://github.com/minetest/minetest/issues/2400 -- Add /setpassword and /clearpassword logging by est31
01:57 Taoki joined #minetest-dev
02:28 est31 man, 100 things...
02:28 est31 minetest progresses quite fast
02:28 est31 and time flies.
02:28 est31 haven't I revoked its fly privilege?
02:29 est31 perhaps its using a hacked client.
02:29 est31 yes, that must be the reason.
02:45 est31 joined #minetest-dev
02:56 Zeno` joined #minetest-dev
03:23 est31 Zeno`, can you have a look at #2531, #2535 and #2537 ?
03:23 ShadowBot https://github.com/minetest/minetest/issues/2531 -- Fix cmake po detection bug by est31
03:23 ShadowBot https://github.com/minetest/minetest/issues/2535 -- Fix Android build on 32 bit by est31
03:23 ShadowBot https://github.com/minetest/minetest/issues/2537 -- Fix minetest.get_craft_recipe function by est31
03:23 est31 alot of fixing :)
03:28 Zeno` How did 2537 creep in?
03:29 hmmmm what's the difference between lua_newtable and lua_createtable?
03:30 hmmmm hrmm... I wonder if anybody depends on genelement IDs being consecutive
03:30 hmmmm give me one good reason why I shouldn't make them opaque handles instead
03:31 Zeno` well 2537 should be merged immediately
03:31 Zeno` the genelement handles?
03:31 hmmmm yeah
03:31 hmmmm the IDs returned by register_decoration and the like
03:32 Zeno` hmm, not sure
03:32 hmmmm for most things IDs can be used in place of names
03:32 Zeno` for lua_createtable() you need to know the number of elements in the table beforehand judging from the Lua doc (referring to your previous question)
03:33 hmmmm like for example let's say you're registering a decoration and you want it to occur in two biomes
03:33 Zeno` But... people rely on them being consecutive?
03:33 hmmmm you can either refer to the biomes by name
03:33 hmmmm or by ID
03:33 hmmmm the ID being the thing returned to your mod by register_biome()
03:33 Zeno` I would never have assumed they would be consecutive but maybe people do, I dunno :3
03:33 hmmmm I want to change that
03:33 hmmmm well, their fault if they do, it's undocumented behavior
03:34 Zeno` Yeah, of course
03:34 hmmmm you could always refer to a generation element by its name, if it's named
03:34 hmmmm but oftentimes they aren't
03:34 hmmmm for example, everybody names biomes, but nobody names ores
03:34 Zeno` I can't think of a *good* reason where I would even contemplate relying on them being consecutive
03:34 est31 Zeno`, doc sais that lua_newtable does the same as lua_createtable(L,0,0)
03:34 est31 the middle param is the allocated size
03:35 est31 as the table has one element, we allocate one
03:35 Zeno` est31, so it's just a convenience thing?
03:35 est31 yes
03:35 hmmmm that's nice to know
03:35 hmmmm I'm going to switch to lua_createtable for perlin noise map apis
03:35 Zeno` well, it's also a performance thing if you know the number of elements I suppose
03:35 est31 yes
03:36 hmmmm thank you
03:36 est31 np
03:37 est31 and about how it sneaked in, read the issue for 2537, #2530.
03:37 ShadowBot https://github.com/minetest/minetest/issues/2530 -- Error when using minetest.get_craft_recipe(item) in a lua file
03:39 Zeno` I'll merge it now if hmmmm agrees
03:39 hmmmm do't you mean 2537?
03:39 hmmmm 2530 is an issue
03:39 hmmmm and yes, +200
03:39 hmmmm LGTM
03:41 Zeno` ok done.
03:41 Zeno` also 2531 is good (I hated that particular file causing builds to fail)
03:42 Zeno` agree, hmmmm?
03:42 hmmmm yes
03:43 hmmmm you realize I can't really give valid input, right?
03:43 hmmmm those are the things that either work or don't, and i have no idea without testing it
03:43 est31 nrzkt already +1ed it.
03:43 Zeno` So he did...
03:44 Zeno` anyway, those 2 are pushed
03:44 est31 fine.
03:46 WarrTab If you're in the mood for reviewing pr's, I just opened #2536 today...
03:46 ShadowBot https://github.com/minetest/minetest/issues/2536 -- Anti-alias all 2D GUI Elements. by Warr1024
03:47 Zeno` I've partially reviewed it :)
03:47 Zeno` nice work
03:47 hmmmm it looks fine to me so far
03:47 WarrTab ah, thanks
03:47 hmmmm WarrTab, the last thing you pushed has problems :/
03:47 WarrTab Oh, which?
03:47 hmmmm angry people with pitchforks
03:48 WarrTab It shouldn't even have any real effect without being enabled in config...
03:48 hmmmm http://pastebin.ubuntu.com/10654682/
03:48 hmmmm it's enabled in the config by default
03:48 hmmmm in any case, I told the guy to disable the setting, and that worked for him
03:49 hmmmm I have no idea how I guessed the two things were interrelated but I turned out to be right
03:49 WarrTab That's pretty weird, was it just the log msg, or was there more?
03:49 hmmmm just the log message
03:49 WarrTab Looks like only one angry person w/ pitchfork so far
03:49 hmmmm well okay I exaggerated
03:50 WarrTab I'm sure it's not gonna be something everyone wants to enable yet.  I figure on-by-default probably requires a feature to "mature" a bit
03:51 WarrTab It may take some time to learn how it interacts with more obscure mod features...
03:51 hmmmm maybe you should change the defaults and push that?
03:51 hmmmm on the other hand, it's getting a lot of exposure and testing!
03:51 WarrTab ha, true
03:51 hmmmm ElectronLibre is the guy to talk to about that
03:52 WarrTab Maybe we should just put one checkbox on the settings gui for "enable experimental stuff" to get exposure
03:52 hmmmm it would help to set debugging log level to info so you can gather more information like the filename it was split from with the garbage text
03:52 hmmmm that's a really good idea actually
03:52 est31 yea
03:52 Zeno` est31, I don't know how to test #2535. I assume you've tested it on 64-bit and on the 32-bit f-droid build?
03:52 ShadowBot https://github.com/minetest/minetest/issues/2535 -- Fix Android build on 32 bit by est31
03:53 est31 I tested it on 64 bit, then there is nerzhul's CI which also tests it on 64 bit. I personally didn't test it on 32 bit, but f-droid people did.
03:54 Zeno` well it *looks* fine :)
03:54 est31 Zeno`, https://botbot.me/freenode/fdroid/2​015-03-22/?msg=34774874&page=3
03:54 est31 begin of discussion: https://botbot.me/freenode/fdroid/2​015-03-22/?msg=34774042&page=3
03:55 Zeno` well, I'm ok with it
03:55 Zeno` I like the experimental stuff as well :)
03:56 Zeno` s/stuff/idea
03:57 Zeno` Ok, I'll merge that based on it being tested by krt and the automated builds
03:58 Zeno` you ok with that reasoning, hmmmm?
04:00 Zeno` WarrTab, do my code comments make sense or am I being vague again? heh
04:00 WarrTab they make sense
04:00 Zeno` weird
04:00 WarrTab Actually, re: the s32 vs u32 thing...
04:01 WarrTab It really would only make sense to use u32 for all coordinates
04:01 WarrTab But rect<u32> then can't have negative width/height
04:01 WarrTab Which would represent mirrored/flipped transforms
04:02 Zeno` yeah, but once they are constrained it doesn't matter
04:02 WarrTab And all my callers seem to want to use rect<s32>
04:02 Zeno` convenience?
04:03 Zeno` I don't know about the history of that
04:03 WarrTab signed/unsigned disagreements are also the cause of a lot of bugs, esp things like buffer overflow vulns...
04:03 Zeno` what was causing the upside down cuboids?
04:03 WarrTab oh, 2 things
04:04 WarrTab One was a quirk of how txr->img seems to alter the original
04:04 WarrTab I didn't fix it, but avoided it, by avoiding repeated conversions using the cache
04:05 Zeno` I wonder why it does that
04:05 WarrTab On android, there's still the inversion issue from before
04:05 Zeno` maybe a performance thing
04:05 WarrTab The one I had caused was a 2d flip, i.e. after render
04:05 WarrTab The one I see on android is a 3d flip, i.e. totally diff coordinate systems
04:06 Zeno` oh. that's not confusing
04:06 Zeno` :/
04:06 Zeno` unless it's endianess related
04:06 Zeno` but that doesn't make sense
04:06 WarrTab I suspect that when you convert an image to a txr, the video driver does some crazy stuff, like reverse row ordering s la .bmp, or even compression
04:06 Zeno` possibly
04:07 WarrTab But trying to pull back from txr to image, you get no help in manyncases
04:07 WarrTab I resolved my android rendering woes by enabling the inventory image hack
04:08 WarrTab Turns out autodetection for it dodn't pick my driver as problematic
04:08 Zeno` hmm
04:08 WarrTab RTT works on my android
04:08 WarrTab But rtt bsck to image doesn't
04:08 WarrTab Which messes up [inventorycube, whose output is an image
04:09 WarrTab Oh, wait, the hack only fixes inventorycube if my scaling filter is ON
04:09 WarrTab Because in that case I'm using the cached image, not txr->img
04:09 WarrTab Never tested that bug with it off...
04:10 WarrTab I should probably give android a regression pass w/ filter off...
04:10 hmmmm Zeno`: sure
04:10 hmmmm I thought screen coordinates for irrlicht are relative
04:10 hmmmm that's why they're s32
04:11 hmmmm u32 is a dimension2d
04:13 WarrTab I could try making sx and sy u32, and might just need to worry about the cast @ getPixel...
04:14 WarrTab Either it's odd that getPixel takes s32, or it's just doing the implicit cast silently already.
04:15 Zeno` yes it implicitly casts
04:15 WarrTab I kind of wonder how slow getPixel/setPixel are; in my experience, they tend to be very slow, and have to check for all sorts of format conversions...
04:19 WarrTab Btw, take a look at the loop in src/client/tile.cpp line 904.  It's a very minor thing, but it seemed funny to me.
04:19 WarrTab It's converting RGBA<-BGRA
04:19 WarrTab It takes each u8 color component and swaps it with the other one
04:20 WarrTab Including swapping G with G, and A with A
04:20 WarrTab :-)
04:22 Zeno` kind of quirky
04:23 Zeno` I would have just put runptr += 4 at the end for a start
04:23 WarrTab me too
04:24 WarrTab So the body would be tmp = *runptr; *runptr = *(runptr + 2); *(runptr + 2) = tmp; runptr += 4;
04:25 WarrTab It feels weird to me to say ptr += 4; I'm used to always having a * sizeof(something) there
04:27 WarrTab I'll pull in those code review changes soon, maybe tomorrow.
04:27 Zeno` well sizeof(unsigned char) aka sizeof(u8) is guaranteed to be 1
04:28 Zeno` but you wouldn't do that anyway
04:28 WarrTab sizeof(u8) is more self-documenting, but I'm not a stickler for self-documenting code...
04:28 Zeno` even if it was u16 *runptr; you'd still do runptr += 4
04:29 Zeno` because pointer arithmetic honours sizes
04:29 WarrTab oh yeah, language quirl
04:29 WarrTab S/.$/k/
04:29 WarrTab I actually always hated that
04:30 WarrTab but when doing pointer walks, I seem to find myself walking with a pointer of s type different than the data elements
04:32 Zeno` yes, but you might be crazy
04:32 Zeno` hehe
04:32 WarrTab I probably am.
04:32 WarrTab No, wait, I actually have proof, come to think of it
04:32 Zeno` the whole loop doesn't need to be written using pointer notation and in this case maybe [] notation would be better
04:34 WarrTab https://gitlab.com/blindpass/gen2 <- proof of my crazy
04:34 WarrTab Zeno`: IIRC pointer walks instead of array walks is a micro-optimization.
04:35 WarrTab Pointer += 4 is faster than idx++, pointer = (idx * 4)
04:36 WarrTab actually, the readme at https://gitlab.com/blindpass​/android/blob/master/README might be better, though it hasn't been updated to latest version
04:37 Zeno` using [] notation is equivalent
04:37 Zeno` there's no optimisation (honest)
04:38 WarrTab the whole "pointer walks are faster" actually predates most compiler optimizations... and a lot of cpu tech too
04:39 Zeno` but in C the [] notation is simply shorthand for a pointer dereference
04:39 WarrTab I'm thinking back in the 286 days
04:39 Zeno` pre-ANSI?
04:39 Zeno` I dunno about pre-ANSI C, but it's been like this since c89
04:40 WarrTab it's calculating the pointer that's theoretically slower
04:40 WarrTab Though not slower in practice of your memory controller is the bottleneck anyway
04:41 Zeno` No idea how... it produces the same ASM (and the asm is as I'd expect even for 286)
04:41 Zeno` but I'll research it later since it might yield some interesting point of history :)
04:42 hmmmm and xor eax, eax used to be faster too
04:42 Hunterz joined #minetest-dev
04:42 hmmmm stuff evolves
04:42 WarrTab Reminds me of http://underhanded.xcott.com/?page_id=15
04:42 Zeno` yeah that's true
04:43 Zeno` hang on, are you say incrementing the pointer by ONE might be faster?
04:43 Zeno` (or might have historically been faster?)
04:43 hmmmm lea edi, dword [ebx + ecx * 4]  vs.  add edi, 4
04:43 WarrTab No, saying that pointer += 4 would be faster than idx++ and using []
04:44 hmmmm I guess that is true in the strict sense of what happens
04:44 WarrTab But knowing gcc, it probably already optimizes that for you
04:44 hmmmm but the compiler might look into what it is you're actually doing and notice
04:44 hmmmm "oh, this guy isn't actually using the counter "i" as he steps through the array"
04:44 hmmmm "i can leverage this by advancing the pointer instead of incrementing the pointer and calculating the effective address
04:45 hmmmm s/pointer/counter/
04:45 Zeno` a[0] actually, internally, has always been "translated" to *a
04:45 WarrTab trying to micro-optimize like that could be bad, at best second-guessing the compiler, and at worst tripping it up
04:45 Zeno` that's it! I'm installing Turbo C
04:45 Zeno` first edition
04:45 hmmmm Watcom C
04:45 Zeno` Watcom is too advanced
04:46 hmmmm watcom used to be teh shit
04:46 hmmmm back in 1992
04:46 Zeno` it had better memory support
04:46 WarrTab man, I was still doing basic back then
04:46 Zeno` can't remember what it was called... (the tech)
04:46 hmmmm I was 1 year old =]
04:46 WarrTab Damn, you're pretty young
04:47 WarrTab I was 11
04:48 Zeno` we might be taling about different things about the micro-optimisation
04:48 Zeno` http://dpaste.com/2VCAEJ0  <--- those two snippets have always been exactly the same
04:49 hmmmm yea
04:49 Zeno` (apart from notational sugar)
04:49 hmmmm what warrtab is talking about is different
04:49 Zeno` I thought so... no wonder I was confused
04:50 hmmmm for (int i = 0; i != ARRAYLEN(thing); i++) { something(thing[i]); }
04:50 WarrTab Those snippets wouldn't be the same on 1980's technology, though ;-)
04:50 hmmmm vs. for (FOO *foo = *thing; foo != thing + sizeof(thing); foo++) { something(foo); }
04:51 WarrTab Though by today's standards they'd both be excruciating
04:51 hmmmm the latter is, at least in theory, faster because it requires less instructions
04:51 hmmmm though the compiler might look at the first snippet and decide you're not actually using the counter for anything other than array indexing and make it equivalent to the latter in the output
04:52 WarrTab In practice, your processor is an order of magnitude faster than RAM, so if your data is large enough for cache misses, you won't notice a diff
04:52 Zeno` I assert that they /were/ exactly the same in 1980 :P
04:53 hmmmm yeah
04:53 WarrTab If it's not larger than the cache, you won't notice the entire loop, probably
04:53 hmmmm in the C language, 2[runptr] == *(2 + runptr) == *(runptr + 2) == runptr[2]
04:53 Zeno` I think the optimisation would be doing runptr++ four times and four times only
04:53 hmmmm -funroll-loops
04:53 hmmmm fun fruit rollups
04:53 Zeno` (back in dem olden days)
04:54 WarrTab Loop unrolling is itself tricky
04:54 Zeno` actually in the olden days you would have made that inline asm lol
04:54 WarrTab fewer loop iterations, BUT uses more cache up, AND affects the branch predictor
04:54 Zeno` not in the olden days
04:55 * hmmmm hides
04:55 Zeno` I'm going to convert all this to bit twiddling
04:55 Zeno` that's how the pros do it
04:55 WarrTab Oh, ugh :-)
04:56 hmmmm guys
04:56 WarrTab RGBA = ((BGRA & 0xff00ff00) ror 16) | (BGRA & 0xff00ff)
04:56 hmmmm let's talk about schematic paths
04:57 hmmmm erm, nevermind
04:58 WarrTab Is there even an operator in c/c++ for binary barrel rotation?
05:00 hmmmm nope
05:00 WarrTab Boo
05:00 hmmmm gcc has excellent recognition of the standard ROL() ROR() macros and converts them from their expansion into the instruction
05:01 WarrTab ah, nice
05:01 hmmmm okay I think what I'm going to do is try to detect if the schematic path is relative of absolute
05:01 hmmmm if it's relative, I'll prepend the mod path
05:02 hmmmm anybody have a problem with this??
05:02 Zeno` I've optimised it: http://dpaste.com/1DR6C6R  can merge?
05:02 Zeno` schematic paths
05:02 Zeno` yeah, I think that's a good idea
05:03 hmmmm the thing is.... do we know if minetest.get_modpath() always returns an absolute path?
05:03 WarrTab I doubt it
05:04 Zeno` This is what I started looking at the other day and that's just one of the questions I tried to answer to myself
05:04 WarrTab I still run the thing on openbsd.  It, and other sort-of-ported-to platforms may use rel paths with run_in_place
05:05 hmmmm I think it is, IF running on a platform with path autodetection (i.e. the big four)
05:05 hmmmm warrtab is right, my KERN_PROC_PATH hack only works on FreeBSD
05:05 hmmmm I should fix this to work with the other 3 popular bsds
05:05 hmmmm also I should fix it so it works on valgrind...
05:06 WarrTab I doubt OpenBSD will ever willingly add an API to get the path of last exec
05:06 WarrTab "What executable image am I running" is a perfectly sensible question to ask on a spawn-paradigm platform like windows...
05:07 WarrTab Less-so on a fork-and-exec-or-maybe-overlay platform like unix
05:07 hmmmm alright
05:07 hmmmm it seems like there really is no way to find the full path on openbsd
05:07 hmmmm that's stupid...
05:08 WarrTab "the full path of what" is the key question
05:08 hmmmm full path of the currently running executable
05:08 WarrTab What you're really asking is "what was the path of my last exec() call"
05:08 hmmmm hopefully absolute path
05:09 hmmmm having an absolute path is absolutely necessay here otherwise my proposed solution just won't work
05:09 hmmmm necessary*
05:10 WarrTab I guess you could throw a hack in for the obscure platforms
05:10 WarrTab Maybe a path prefixed with ./ or something to force relative interpretation...?
05:10 Zeno` or maybe the full path is in argv[0]... who knows
05:10 WarrTab Though I guess that's still backwards from what you want
05:11 WarrTab Argv[0] could very well be an interpreter or launcher or hardlink or wrapper or any number of bizarre things
05:11 hmmmm openbsd doesn't have procfs, right?
05:11 hmmmm just checking
05:11 WarrTab I think execve or something lets you pass anything you want as argv[0]
05:12 Zeno` secret messages
05:12 WarrTab Openbsd actually recently ripped procfs support out completely
05:12 hmmmm awesome
05:12 WarrTab You could add a cmdline option like --abspath
05:12 hmmmm don't we have that??
05:12 hmmmm hrm
05:13 WarrTab We could trust argv[0] under MOST circumstances and use --abspath to work around the rest
05:13 WarrTab ./minetest --abspath=`pwd`
05:14 hmmmm you bring up an excellent point
05:14 hmmmm why do we even care about the path of the executable
05:14 WarrTab I think I might have used ./ as abs path in porting when I last played with BSD support
05:14 hmmmm why aren't we using getcwd()
05:14 WarrTab Yep
05:14 WarrTab For run_in_place, makes the most sense
05:14 hmmmm i don't know this is what celeron was doing and we all just went along with it and never performed any critical thinking
05:15 WarrTab For non-run_in_place, those paths oughtta be compiled in
05:16 WarrTab I think cwd == dir of executable is a reasonable assumption on most platforms
05:16 hmmmm that would also fix the freebsd valgrind problem
05:16 WarrTab Even on windows dbl-clicking an icon, runs the program by default from its own dir
05:17 Zeno` does anyone use run_in_place?
05:17 WarrTab I do
05:17 hmmmm me :)
05:17 Zeno` I dunno what it does
05:17 hmmmm i think the majority of people use run_in_place
05:17 WarrTab run-in-not-place is for root installs
05:17 Zeno` I've never used it and I don't do "root installs"
05:17 WarrTab Windows is ONLY run_in_place IIRC
05:17 hmmmm yep
05:17 Zeno` I have three different directories where minetest bin is actually
05:18 Zeno` all of them in my home dir
05:18 Zeno` and everything else in ~/.minetest/
05:18 Zeno` just works(TM)
05:19 WarrTab I actually run_in_place, where _place just so happens to be ~/.minetest, with a rats' nest of symlinks :-)
05:19 hmmmm here's the patch that added initializePaths:  https://github.com/minetest/minetest/commi​t/6b6c2d37ea1f9075c4fbf0d7e2d52e527e1f86aa
05:19 hmmmm we need to ask celeron what the reasoning behind this is before changing it
05:19 hmmmm also we need to expect that changing it to the proper behavior will break things
05:20 hmmmm celeron55:  i am highlighing your nick
05:23 Zeno` after looking at that function in porting (but the modern version) I wonder how my setup even works considering I don't use RUN_IN_PLACE
05:23 hmmmm how minetest works is nothing short of a miracle
05:23 WarrTab "use cwd" was how I originally fixed OpenBSD portability in https://github.com/minetest/minetest/commi​t/2636c92075196b4c2cd65327b1f839f1e8919b83
05:24 Zeno` oh // Get path to executable
05:25 Zeno` so it seems on linux that it still gets the executable even if !defined RUN_IN_PLACE
05:25 Zeno` I won't worry about it. Works, so *shrug*. Someone else can deal with that terrible function heh
05:27 WarrTab The entire concept of "path to executable" is really a Windowsism, and even on that platform, as of Windows 8 at least, programs, program data, and config go in 3 different places now.
05:28 WarrTab On unix, programs are generally meant to get data from compiled-in paths, cmdline, cwd, or ~/something...
05:29 WarrTab It's actually kind of weird to have minetest exec in ~/.minetest/bin instead of ~/bin
05:30 est31 what is ~/bin?
05:30 WarrTab Except I'm not even sure if MT compiles on OpenBSD with RUN_IN_PLACE=0 w/o patches and hacks
05:30 est31 on which os is it convention?
05:30 hmmmm https://github.com/minetest/minetes​t/issues/2527#issuecomment-84811738
05:30 hmmmm lol proller
05:31 est31 yea
05:32 WarrTab est31 no idea on the convention, but where else do you put stuff to add to $PATH?
05:33 est31 I don't have a user-wide path. but it is convention to have a ~/.$APPLNAME directory, mostly however for data
05:33 WarrTab Btw, re: red sun, it seems there are still some places in code that are using images w/ specific pixel offsets that get thrown off...
05:33 WarrTab Sifns lib was one, sun color is the other.
05:34 WarrTab 2 potential fixes I see so far:
05:34 WarrTab 1. Don't resize textures until they're bound to a mesh; could be complicated based on acces, though
05:35 WarrTab 2. Make the sun color thing relative to image size instead of absolute
05:35 Zeno` I have minetest in ~/minetest-build-debug ~/minetest-build-release and ~/minetest-build-stable
05:35 WarrTab est31 what's $APPLNAME?
05:35 est31 the application's name
05:35 * VanessaE peeks in
05:35 est31 I have alot of ~/.$omething directories...
05:36 Zeno` these aren't .skfjksjf dirs though
05:36 WarrTab so you have to type out the path for everything?  Or you have a lot of stuff in $PATH?
05:36 VanessaE WarrTab: red sun....you know, I had noticed something was a little "off" about HDX's sun texture yesterday -- seemed too red.  guess that explains it.
05:36 Zeno` I type the full path
05:36 VanessaE (I didn't think anything of it at the time)
05:37 VanessaE (I assumed my tone map just needed adjusted)
05:37 Zeno` (well I don't because I have scripts, but I effectively type the full path)
05:37 est31 WarrTab, I do ctrl+R
05:37 WarrTab vanessae: it needed not adjusted is the actual issue :-)
05:37 Zeno` I'm bisecting it now
05:37 VanessaE WarrTab: heh ok
05:38 WarrTab zeno: it's the image scaling thing
05:38 est31 yes its already bisected
05:38 Zeno` oh it's adready been bisected? ok
05:38 WarrTab As a short-term fix, we could set texture_min_size=1 in defaultsettimgs.cpp
05:39 WarrTab Apparently our default of 16 as "effectively disabled by default" wasn't quite disabled enough
05:39 WarrTab Friggin' 1px textures...
05:40 WarrTab Might be just as quick to fix the tonemap code though
05:40 WarrTab If anyone knows where it is...
05:42 WarrTab Ah, got it
05:42 WarrTab sky.cpp line 163
05:42 WarrTab That 511 needs to not be a literal
05:42 WarrTab It should be texture height - 1, I guess
05:43 WarrTab It's a 1-line fix; I'd do it myself, but not near a computer suitable for it
05:45 WarrTab To be REALLY correct, offset should be calculated separately for sun/moon, incase the have different size tonemaps
05:46 Warr1024 joined #minetest-dev
05:46 WarrTab Meh, maybe I'll whip up a pr
05:55 jin_xi joined #minetest-dev
05:56 Warr1024 btw, didn't know you could pull specific texels from a texture...
05:57 Warr1024 makes me wonder whether (1) sun/moon tonemaps don't work on android, or (2) we can use them to work around the texture->image issues we've been having with RTT
06:04 Zeno` a) I imagine that u8 *texels = (u8 *)m_sun_tonemap->lock(ETLM_READ_ONLY); would be more efficient  and b) why is the returned pointer not checked for NULL?
06:05 VanessaE ok what is with the HORRIBLE lag while crafting stuff?
06:06 VanessaE (in singleplayer)
06:06 Zeno` it's been optimised
06:06 VanessaE (I'm at f6f8250 at the moment)
06:07 Zeno` i was joking, but I don't see the lag?
06:09 VanessaE placing items in the craft grid results in them jumping back and forth between the grid and inventory
06:09 VanessaE the lag is small but it's enough to be REALLY annoying
06:09 * Zeno` looks again
06:10 VanessaE it's like there's no inventory prediction anymore
06:12 Zeno` inventory in the formspec or on the HUD?
06:12 VanessaE in the formspec.
06:12 Zeno` I don't see it and I'm using a debug build with no LuaJIT
06:12 VanessaE moving items from inventory slots to the crafting grid.
06:12 Zeno` (at HEAD)
06:12 * Zeno` tries a dbuilder game
06:13 VanessaE can you pull dreambuilder and see if it's just broken there?
06:13 Zeno` I'm testing an old version of dreambuilder... taking ages to start up heh
06:16 Zeno` I see it now with unified inventory (if that's what the mod is)
06:16 * Zeno` tries release build
06:18 Warr1024 are you testing on a server, or singleplayer?
06:18 VanessaE singleplayer
06:18 Zeno` singleplayer
06:18 VanessaE ninja'd :)
06:18 Zeno` so I was using the same as VanessaE
06:18 Zeno` heh
06:18 VanessaE Zeno`:  how old is "old"?
06:19 Zeno` ancient
06:19 VanessaE just wondering, in case it's u_i that's broken
06:19 Warr1024 ugh, my fix isn't working
06:20 Zeno` ok, let me look...
06:20 Zeno` VanessaE, 3f99e214d48a4eea12420a5ea97aa62c838c6e0b
06:20 Zeno` Warr1024, I suppose you could just avoid upscaling 1px images
06:20 VanessaE well that's not super old, but reasonably so.
06:20 Warr1024 Hm, I guess that could work.
06:21 Warr1024 I think that was proller's workaround
06:21 Warr1024 since I suppose 1px images won't experience blurring anyway
06:21 Zeno` I never look there (don't want to taint myself heh)
06:21 Warr1024 ugh, seems like a cop-out to special-case it :-)
06:22 Zeno` dunno if it's a cop-out
06:22 Zeno` :P
06:22 Zeno` probably an optimisation even
06:22 Zeno` VanessaE, I notice the lag with LuaJIT and release build also
06:23 VanessaE Zeno`: any chance this is a u_i bug?
06:23 Zeno` VanessaE, I'd be guessing without trying to find the cause of it :)
06:23 Zeno` But it never used to be like that
06:23 Zeno` Well, I don't think it did... I'm sure I would have noticed something that annoying
06:25 VanessaE it feels very much like using a chest on a laggy server
06:25 VanessaE or a crafting table in Realtest, on a bad day
06:25 Zeno` yes
06:28 Warr1024 #2538
06:28 ShadowBot https://github.com/minetest/minetest/issues/2538 -- Fix for sun/moon tonemaps: dont upscale 1px images. by Warr1024
06:30 Warr1024 someone should tell proller that there IS an "already fixed in freeminer" tag for issues: it's called him opening up a PR and sending the fix upstream :-)
06:32 Warr1024 ooh, guiscaling actually anti-aliases the menu background too; I hadn't noticed that I had covered that too.
06:33 Zeno` I don't like the extra parenthesis :P
06:35 Warr1024 paranoia about compilers that ignore standards when it comes to order of ops
06:36 Warr1024 and, frankly, novice devs who misread them
06:36 Warr1024 The guy who taught me that feared the former, but I've learned to fear the latter more often.
06:38 Warr1024 of course, you can fix any style issues you come across when you commit it, I suppose.
06:38 Warr1024 As long as you don't end up introducing a bug I get blamed for :-P
06:38 Zeno` https://gist.github.com/Zeno-/3e6e2ae6644e5c8c7e29
06:39 Zeno` Why? It's better to give you the fix so you get blamed for the bug isn't it?
06:39 Zeno` :p
06:39 Warr1024 composing 2 images together doesn't work very well when one of them is a high-res image from a texture pack, and the other is not texture-packed.
06:40 Warr1024 *looks* okay.  I take it it runs okay?
06:40 Warr1024 Not a fan of your extra whitespace either :-)
06:40 Zeno` Didn't test it
06:41 Zeno` what whitespace?
06:41 Warr1024 lines 14 and 15
06:41 Zeno` mistake :)
06:41 Warr1024 I do like the early return style, though, thanks.
06:41 Zeno` yw
06:41 Zeno` haha :D
06:42 Warr1024 I straight-ported my old code, and the old code couldn't do that.
06:42 Warr1024 I get complaints about return/break/continue use occasionally
06:42 Warr1024 flow control purists kind of hate them
06:42 Zeno` oh fix that opening brace as well?
06:42 Zeno` (for the start of the function)
06:42 Warr1024 but I hate indenting to the point where shit is all crammed on the rightmost few columns..
06:43 Zeno` yeah, purists would say you don't need early returns, continue, break, goto, etc
06:43 Zeno` but realists are a bit more... hmm, realistic? :)
06:43 Zeno` of course you don't *Need* them, but they sure make the code cleaner (especially the indentation levels)
06:44 est31 doublists are even more.
06:44 Warr1024 goto I don't use, myself; not so much because of dogma, as I just (1) haven't had to, and (2) can't remember label syntax in C/C++.
06:44 Zeno` goto use case is rare but there are valid cases
06:44 est31 not realistic but doublistic
06:44 Hunterz joined #minetest-dev
06:44 Zeno` wtf is doublistic? lol
06:45 Zeno` oh probably shouldn't use switch either... huge goto-like jump table... horrible
06:45 est31 mhh you are right, reals are better than doubles
06:45 Zeno` that has to be the worst joke I've ever head lmao :D
06:45 est31 reals are really uncountable though.
06:46 Zeno` that's why I don't use them
06:46 Zeno` integers are all that's required
06:46 est31 there are reals that no c program can output for any input.
06:46 est31 input which has an end.
06:47 Zeno` unreal
06:48 Zeno` Warr1024, "The guy who taught me was paranoid about compilers that ignore standards when it comes to order of ops"
06:48 Zeno` is he on medication now?
06:49 Zeno` lol, I find that really funny (sorry)
06:50 Warr1024 Zeno`: you get burned once, you learn to be careful
06:50 Zeno` well he missed an op
06:50 Warr1024 oh?
06:50 Zeno` if (((dim.Width) <= 1 || ((dim.Height) <= 1))
06:50 Warr1024 cute
06:51 Zeno` anyway it must have been a very bad compiler :(
06:51 Warr1024 there are no shortage of those, you just don't hear much about them...
06:51 jin_xi +1 for extra parens from both a lisper and user of many different languages all with subtly different rules for precedence
06:51 Zeno` the *really* bad ones might even ignore precedence of parenthesis
06:52 Warr1024 ha
06:52 Warr1024 jin_xi: thanks, nice to be appreciated for a change ;-)
06:52 Zeno` harsh crowd
06:52 Warr1024 I also don't really bother to learn the intricacies of order of ops for any particular language
06:53 Zeno` Me either
06:53 Warr1024 the "my dear aunt sally" ones aren't so bad, but the bit twiddling ones can be weird.
06:53 Warr1024 parens help me not have to worry about those.
06:53 Zeno` I just trust the compiler to do what I meant
06:53 Warr1024 some languages don't offer non-bitwise boolean ones
06:53 Warr1024 lol
06:54 Warr1024 no, compilers generally only compile what you type, not what you mean :-)
06:54 Warr1024 #pragma you know what I'm sayin', right?
06:54 Zeno` heh
06:54 Zeno` So they don't guess?
06:54 Zeno` stupid things
06:55 Warr1024 actually, sometimes they do, and that can be problematic.
06:55 Zeno` Well, guess is the wrong word. They should really look at the context and determine what I *really* meant to type but typed incorrectly and silently correct me
06:55 Warr1024 if you're working on something sensitive enough, like driver code, then the compiler's optimizations based on its guess of what you intended can be wrong...
06:56 Warr1024 When LibreSSL first forked from OpenSSL, there were a number of downstream projects to try to port it to other operating systems.
06:56 Warr1024 but these had problems, such as leakage of sensitive informaion
06:56 Zeno` you know my words in the last 10 minutes have been dripping with sarcasm, right?
06:57 Warr1024 one of the culprits was the fact that compilers like to optimize away bzero before free
06:57 Zeno` sometimes people don't realise when I'm being sarcastic... probably the nature of the medium we're communicating on
06:57 Warr1024 Zeno`: was that before or after the mention of extra parens?
06:57 Zeno` well, after that
06:58 Warr1024 well, just because you were being facetious about compilers trying to "guess" what you mean doesn't mean that they don't actually do that :-)
06:58 Zeno` oh, I do know :)
06:59 Warr1024 what's the story on the PR, btw?  Were you going to merge it, or kick back some code review comments, or pass it on for further review?
06:59 Warr1024 it's a bugfix, but probably not ultra-critical
06:59 Zeno` oh yeah.. forgot about that
06:59 Warr1024 I mean, a red sun is damn creepy, but it's not exactly a segfault :-)
07:00 Zeno` I suppose I can leave the extra indentation
07:01 Warr1024 I don't mind any of the changes you had proposed
07:02 Zeno` they make the PR less trivial
07:02 Warr1024 though I suspect I'll probably over-parenthesize future diffs too...
07:02 Zeno` and I'd then have to get approval from another dev :)
07:02 Warr1024 just typing the space after if and for is damn hard to do :-)
07:02 Warr1024 well, you can split the patch
07:02 Zeno` So I left it as-is because it's obvious that it's a trivial fix
07:02 Warr1024 submit the critical parts, and then do a style pass later
07:03 Warr1024 eh, it's not really difficult to understand the code either way
07:03 Zeno` correct
07:04 Warr1024 awesome
07:05 Warr1024 should we close 2527, or is there some level of confirmation of the fix necessar?
07:05 Zeno` yeah I'm doing it now but got distracted :)
07:06 Warr1024 awesome, only one more reported issue related to that upscale patch :-)
07:06 Zeno` does github have an API?
07:06 Zeno` would be nice to automate some of this
07:06 Warr1024 yeah, I haven't messed with it much though.
07:06 Warr1024 everybody who's anybody has an API :-)
07:06 Zeno` true :)
07:07 Zeno` Secure Connection Failed
07:07 Zeno` ok well I give up
07:07 Zeno` lol
07:07 Zeno` github has been really bad for me for the last couple of days
07:07 Zeno` pages not loading, things not being formatted, avatars displayed incorrectly, etc etc etc
07:08 Warr1024 yeah, I guess I'm done for the night too.
07:08 Zeno` I'd better cook dinner
07:08 Warr1024 I think guiscaling could use a bit of time to gather some reviews and testing...
07:08 Warr1024 later
07:08 Warr1024 thanks for the quick fixes, btw.
07:08 Zeno` bbl as well
07:22 blaze joined #minetest-dev
07:49 celeron55 hmmmm: the path detection code is indeed rather unconventional, but it has done its job of allowing users and developers to not care about CWD quite well
07:49 celeron55 i don't remember what the original case was that made me add that
07:51 hmmmm what would break if it were changed to only use cwd
07:51 celeron55 oh that commit actually does two things
07:52 celeron55 it adds RUN_IN_PLACE, AND implements it using a system that primarily uses the executable's path
07:52 hmmmm i see
07:52 hmmmm ahh
07:52 celeron55 hmmmm: maybe not, but it would probably break many user's setups and some build systems that have weird stuff going on with CWD
07:53 hmmmm so if somebody wanted to run minetest like projects/dev/minetest/bin/minetest it'd get the assets from the correct place
07:53 hmmmm right this is the correct "spirit" of RUN_IN_PLACE.. it's running relative to where the executable is supposed to be
07:53 celeron55 and it would start a fight of whether CWD should be in the root of minetest or in bin and what's the difference between a run-in-place and non-run-in-place versions regarding to that
07:54 hmmmm the only problem is that on some platforms, getting the executable path is hard
07:54 hmmmm it can't be done on OpenBSD, for example.  simply can't
07:54 celeron55 i'm not arguing that that's the only way to do it, but it has served us during the four years quite well if you ask me
07:54 hmmmm on FreeBSD, my sysctl code actually breaks valgrind
07:55 hmmmm and that's sort of a bummer
07:57 hmmmm okay I think I know what to do
07:58 celeron55 the code is ugly though
07:58 celeron55 but that's not a problem with what the code does
07:59 celeron55 (just a code-organizational issue)
08:07 est31 hmmmm, what about  /proc/curproc/file  ?
08:08 hmmmm procfs is not used by default on freebsd and netbsd; it doesn't exist on openbsd at all
08:08 hmmmm you cannot rely on the existence of procfs
08:08 est31 good to know.
08:08 est31 there is no $0 trick?
08:08 hmmmm nope.  on openbsd they expect you to use the cwd for these sorts of situations
08:08 hmmmm which obviously has problems
08:09 est31 I always start my minetest from my desktop
08:10 hmmmm god dammit l_mapgen.cpp is such a mess =]
08:10 hmmmm was out all day and I wanted to get some serious stuff done
08:10 hmmmm night all
08:10 est31 bye
08:12 est31 when its their philosophy, follow it.
08:12 est31 just dont force all users to it.
08:13 nrzkt joined #minetest-dev
08:25 Calinou joined #minetest-dev
08:37 SopaXorzTaker joined #minetest-dev
08:50 kilbith joined #minetest-dev
10:05 SopaXorzTaker joined #minetest-dev
10:07 est31 joined #minetest-dev
10:10 est31 finally, minetest is also available in the f-droid app store! https://f-droid.org/repository/browse/?fdf​ilter=mine&amp;fdid=net.minetest.minetest
10:15 rom1504 joined #minetest-dev
10:24 est31 and the proper URL is https://f-droid.org/repository/br​owse/?fdid=net.minetest.minetest
10:27 Calinou they have an IRC btw, #fdroid
10:54 Player_2 joined #minetest-dev
11:12 Zeno` joined #minetest-dev
11:13 Calinou joined #minetest-dev
11:27 FR^2 joined #minetest-dev
11:27 MinetestForFun joined #minetest-dev
11:34 Ritchie joined #minetest-dev
11:36 SopaXorzTaker joined #minetest-dev
12:22 Zeno` joined #minetest-dev
12:57 Zeno` kinda quiet
13:26 Zeno` nrzkt, are you awake?
13:26 est31 https://github.com/minetest/minete​st/pull/2540#issuecomment-84995376
13:26 est31 seems so
13:27 MinetestForFun joined #minetest-dev
13:29 Zeno` github is not working for me very well :/
13:30 est31 send them a mail, or complain to support
13:30 est31 they are a corp
13:30 est31 I have a nasty github issue too
13:30 est31 but old one and I can live with
13:31 Zeno` I have
13:31 Zeno` :)
13:31 Zeno` The web side of github is basically unusable for me atm
13:32 est31 when did you ask them
13:32 Zeno` about 20 minutes ago
13:33 Zeno` it's been slowly getting worse for me over the last 5-7 days (on all 4 of my computers... browser doesn't matter)
13:33 est31 I'm 100 percent sure its the alf. can you reproduce it with non-alf accounts?
13:33 * est31 lost a bad joke again. where is it?
13:34 Zeno` lol
13:35 kilbith https://github.com/minetest/minetest/issues/2541
13:35 kilbith thanks for chasing the bug ^
13:39 Zeno` ?
13:41 nrzkt i looked at the code, the problem is serverside for me. It's not a network bug, the sent content is not right
13:43 Zeno` I'm sorry, but are you serious?
13:43 nrzkt the packet sending is a raw copy from asyncrunstep and the packet decoding is strictly exact, else everybody would have a bug. Then the only think possible is an object with wrong datas on server
13:43 Zeno` The server doesn't send packets?
13:43 nrzkt only thing*
13:43 nrzkt hmm, why do you say that ?
13:44 nrzkt the server send packets because the packet is handled and this exception is triggered
13:44 Zeno` because you said "the problem is serverside for me"
13:45 Zeno` I mean... it's the second time I've seen that bug report now
13:45 kilbith it's obviously, unsurprisingly not a server bug (tm) ...
13:45 nrzkt yes, the problem is on the datas written to the packet, but because the packet writing is trivial (pkt.putRawString(datas.c_str(), datas.size());)
13:45 Zeno` there was a very similar one yesterday
13:46 Zeno` Ok, let's put it this way.  Why do the servers suddenly "have the wrong data"?
13:47 nrzkt it's only into 1 world of this player, as he said in the pr
13:47 nrzkt then the condition is not matched every time
13:47 Zeno` Yesterday's bug report was from LazyJ as well?
13:47 est31 yes
13:47 nrzkt it's this report
13:47 est31 the one you wanted to rebase
13:48 Zeno` I wanted to rebase?
13:48 est31 the sun problem
13:48 est31 umm bisect
13:49 Zeno` so it's now fixed?
13:49 est31 I havent reproduced it
13:50 Zeno` wtf does the sun problem have to do with something the server sends anyway?
13:51 nrzkt est31 it's not related, the packet in this report isn't related to sun, it's ACTIVEOBJECT_REMOVE_ADD, sun is not an activeobject, right ?
13:51 est31 sorry perhaps I got sth wrong
13:51 * est31 needs sleep
13:53 est31 bye
13:53 err404 joined #minetest-dev
13:54 Zeno` I might have a break as well. I'm very confused atm lol
14:06 cd2 joined #minetest-dev
14:15 PilzAdam joined #minetest-dev
14:46 nrzkt PilzAdam: how signs_lib generate their names ?
14:48 PilzAdam https://github.com/VanessaE/homedecor_mod​pack/blob/master/signs_lib/init.lua#L442
14:49 PilzAdam basically a huge [combine
14:49 nrzkt is this a luaentitysao ?
14:50 PilzAdam yes, the texture is set to an entity
14:50 PilzAdam this is the only way to dynamically change textures
14:51 nrzkt the exception is triggered because of this call server side: https://github.com/minetest/minete​st/blob/master/src/server.cpp#L757
14:52 nrzkt which refers to this: https://github.com/minetest/minetest/​blob/master/src/content_sao.cpp#L353
14:52 nrzkt this is the long string forger
14:55 PilzAdam ObjectProperties::serialize uses writeU16(os, textures.size());
14:55 PilzAdam maybe the texture name contains more than 65000 chars?
14:56 PilzAdam oh wait, that is the number of textures
14:56 nrzkt yes
14:57 PilzAdam serializeString properly checks the string the length, so that isn't the problem
14:57 nrzkt yes, idem with long string
14:58 PilzAdam do you have a way to reliably reproduce it?
14:59 nrzkt at this moment no, because i don't have the user environment
14:59 nrzkt if we cannot read the size on client side, it's because there is nothing to read
15:03 nrzkt how can this be possible
15:03 nrzkt the serializer and the deserialize are correct, i don't see a problem on it
15:05 nrzkt the only place where we deserialize long strings are: deSerializeLongString
15:05 nrzkt is: https://github.com/minetest/minetest/​blob/master/src/content_cao.cpp#L646
15:06 nrzkt then the num_messages is incorrect, because we have read the previous datas in the CAO
15:07 nrzkt https://github.com/minetest/minetest/​blob/master/src/content_sao.cpp#L805
15:07 nrzkt it's written here, the message number and the message map
15:08 nrzkt err: https://github.com/minetest/minetest/​blob/master/src/content_sao.cpp#L367 , not the playerSAO
15:11 Zeno` joined #minetest-dev
15:17 nrzkt hmm... the "Malformed packet read" is triggered by NetworkPacket, we want to read outside of the packet size
15:18 nrzkt this match the serialization error given by deSerializeLongString
15:20 hmmmm joined #minetest-dev
15:22 * VanessaE wanders in
15:23 DFeniks joined #minetest-dev
15:29 Zeno` It'd be nice if this could be reproduced somehow
15:36 VanessaE signs_lib's string size is kinda limited - I've tested it (under LuaJIT) to be able to handle some 3 or 4K in a sign (even though the sign can theoretically only display about 1k, and that's if they're all 'i' or something)
15:36 VanessaE so you can at least be confident that it's not running up against some serialization limit in Lua or so.
15:36 nrzkt i don't think it's related to size our packet size and buffer size are correct
15:37 VanessaE (that is, it's limited on input and on rendering to not go over that 3 or 4k, whatever it was)
15:39 VanessaE by serialization limit I mean, just for example, the known bug in LuaJIT where it can't handle more than 64k.
15:40 nrzkt in packets 16k or 4.2B , but generally 4.2B
15:49 VanessaE Zeno`: about the crafting delay...  could it be related to the get-all-recipes commits, since it only seems to happen under U_I and that mod uses those?
15:50 Zeno` VanessaE, I suppose it could be yeah
15:53 Zeno` strange, or not?, is that there is a possible memory leak in deSerializeLongString
15:54 Zeno` caused by clientpackethandler.cpp line 822
15:57 nrzkt 822 ? are you sure ? it's not the same packet
15:57 nrzkt https://github.com/minetest/minetest/blob/mas​ter/src/network/clientpackethandler.cpp#L822
16:01 Zeno` as I said, it's probably a coincidence but that is where the possible memory leak is occurring
16:01 Zeno` wtf
16:02 * Zeno` checks that he's at HEAD
16:02 Zeno` line 815
16:04 Warr1024 joined #minetest-dev
16:06 nrzkt you are not on the right packet zeno
16:06 nrzkt it's not this packet as the backtrace said it's ACTIVEOBJECT_REMOVE_ADD
16:06 nrzkt https://github.com/minetest/minetest/blob/mas​ter/src/network/clientpackethandler.cpp#L365
16:07 Zeno` I am saying that there is a possible memory leak caused by line 815 of clientpackethandler.cpp
16:07 Zeno` Well, I'm not saying it, I'm just reporting what valgrind is telling me
16:08 Zeno` and either it's a coincidence or not :)
16:08 nrzkt why ? std::string is not a pointer, and is not a pointer too
16:08 Zeno` it's the Buffer I imagine
16:09 nrzkt the buf[4] ?
16:09 Zeno` onl line 124 of serialize.cpp
16:10 Zeno` I'm not saying this *is* an error
16:10 Zeno` I saying that valgrind reports it
16:12 SopaXorzTaker joined #minetest-dev
16:12 nrzkt very strange why are we using Buffer<char> there ? instead of writing directly to std::string ?
16:12 Zeno` no idea
16:14 nrzkt it's useful as i see in my first test
16:15 Zeno` I'll run valgrind again
16:17 nrzkt Zeno` can you review https://github.com/nerzhul/minetest/commit​/7ad167787eef6783daccfe6680a06a03905eb74d please ? I improve a little bit the interaction between Connection senders with the given packet by removing the oldForgePacket copy, replacing it by a reference
16:17 nrzkt this will improve a little bit more our network stack performance
16:26 Zeno` I'm more interested in fixing (potential) bugs than performance atm :)
16:27 nrzkt i agree with you, i only find this useful improvement when i look at the network stack today :)
16:27 VanessaE maybe a bug freeze needs to be declared?
16:28 VanessaE no performance changes, no features, strictly only bug fixes
16:28 Zeno` Not much point in optimising something that doesn't work lol (if there is a bug)
16:28 VanessaE I think we need a fairly long period with only this alloed.
16:28 VanessaE allowed*
16:29 Zeno` To be clear I'm not saying the bugs are network related; but there *are* bugs
16:29 nrzkt VanessaE, 0.4.12 is young. 1 month too early, 1 or 2 months more can be useful, bugtracking must be done in parallel of the devel
16:29 VanessaE and then at the end of said freeze, make a new release.
16:29 VanessaE nrzkt: so?  0.4.12 is a pretty nasty release (not as bad as 0.4.11, but bad)
16:29 Zeno` they may or may not be network related; either way they need to be fixed before worrying about optimisation IMO
16:29 nrzkt no problem :p
16:30 Zeno` hey 0.4.11 was very fast
16:30 VanessaE Zeno`: fast at crashing? ;)
16:30 Zeno` 50x faster than 0.4.10
16:31 Zeno` no :P
16:31 Zeno` but there were some major hiccups yeah
16:31 VanessaE but anyway I'm saying zero new features, not even the most trivial.  no performance tuning, nothing like that.  All efforts directed at fixing bugs, regardless of who made them, how they got started, or how big or trivial they are.
16:31 VanessaE and keep at it until enough are declared fixed that it's worth a new release.
16:32 nrzkt we don't have really new features on this devel version
16:32 VanessaE constant development is useless if it results in buggy code
16:32 Zeno` Does there need to be a "feature freeze" for this to happen though? It's common sense to fix bugs before optimising
16:32 kilbith Zeno`, "faster" is relative...
16:32 Zeno` kilbith, no... I have objective tests
16:32 kilbith on your i7, maybe yeah
16:32 VanessaE kilbith: yeah -- one function is 5x faster, another is 3x, another is 10x... that's already 18x. ;)
16:33 kilbith not the same output on my celeron
16:33 Zeno` no; CPU independent
16:33 Zeno` my profiling methodology doesn't care about cores or how fast the CPU is
16:34 Zeno` it's just "self cost (relative)"
16:34 Zeno` no more, no less, and there cannot be argument :P
16:34 kilbith the announced +20 FPS or +30 FPS on each of earlier commits was not noticable at all for me
16:34 kilbith your commits*
16:34 Zeno` FPS is a bogus measurement
16:35 kilbith this is what you claimed in the PRs
16:35 Zeno` I really quoted FPS gains?
16:35 kilbith yep
16:35 Zeno` If so I was wrong.
16:35 VanessaE kilbith: RAM performance will kill those FPS improvements believe it or not
16:35 VanessaE because so much of Minetest is CPU-bound instead of being handled by the graphics device
16:35 Zeno` I normally only ever quote cycle percentage relative percentages
16:36 VanessaE which in turn makes it depend on RAM and bus performance as well
16:36 kilbith but there was certainly an overall optimizing, i observe +10FPS between .10 and .11
16:36 Zeno` maybe at the start I got carried away, it's so long ago I can't remember. But, yes, FPS is not a valid measurement
16:38 Zeno` I can't imagine myself quoting FPS improvements and not qualifying the statement with "on my machine"
16:38 Zeno` but who knows... I am crazy after all
16:38 kilbith in *some* or your PRs
16:38 kilbith but anyways, doesn't matter now
16:38 kilbith *of
16:53 SopaXorzTaker joined #minetest-dev
16:55 Zeno` nrzkt: http://dpaste.com/3ZQS615
16:55 Zeno` may or may not be relevant... it could be just a coincidence as I mentioned
16:56 nrzkt 955 blocks ? it's huge
16:56 nrzkt This can explain some memory leaks on server, if the deserializeLongString has memory problems :(
16:57 Zeno` oh, those are particles
16:57 Zeno` should just disable that crap
16:57 nrzkt i go back home, see you !
16:58 Zeno` it's not the same possible leak as I got before
16:58 Zeno` oh, he's gone
16:58 VanessaE he'll be back
16:58 Zeno` 3AM here
16:58 Zeno` I think I must rest :)
17:00 roniz joined #minetest-dev
17:00 Zeno` http://dpaste.com/1R891VG
17:03 Hunterz joined #minetest-dev
17:05 jin_xi joined #minetest-dev
17:14 Wayward_One joined #minetest-dev
17:26 Jordach joined #minetest-dev
17:29 MinetestForFun joined #minetest-dev
17:38 Tablet_One joined #minetest-dev
17:39 Tablet_Two joined #minetest-dev
17:39 Krock joined #minetest-dev
17:41 ElectronLibre joined #minetest-dev
17:51 Tablet_One joined #minetest-dev
17:56 paramat joined #minetest-dev
18:01 paramat hi hmmmm please could you approve my generate_ores/decos PR? #2533
18:01 ShadowBot https://github.com/minetest/minetest/issues/2533 -- lua_api/l_mapgen: Fix volume of minetest.generate_ores/decorations to mapchunk volume by paramat
18:31 roniz_ joined #minetest-dev
18:34 rubenwardy joined #minetest-dev
18:40 est31 joined #minetest-dev
18:59 shadowzone joined #minetest-dev
19:04 misprint joined #minetest-dev
19:04 ekem joined #minetest-dev
19:10 shadowzone joined #minetest-dev
19:30 Tesseract joined #minetest-dev
19:38 FR^2 joined #minetest-dev
19:40 paramat left #minetest-dev
19:46 hmmmm joined #minetest-dev
19:55 MinetestForFun joined #minetest-dev
20:04 shadowzone joined #minetest-dev
20:06 casimir joined #minetest-dev
20:08 casimir Greetings. In just updated my minetest after a while. And I'm mildly shocked. Why do no-fancy leaves look that ugly? Why did it crash when I wanted to craft something, and why do I have damage-flash and sound when damage is turned of? What is happening to this game?
20:10 hmmmm do you have anisotropic, bilinear, or trilinear filtering enabled?
20:11 casimir No. It has nothing to do with this.
20:12 hmmmm you're sure you don't have them enabled?
20:12 hmmmm you shouldn't notice any 'ugliness' with leaves in that case
20:12 hmmmm could you take a screenshot of what you mean?
20:12 casimir I'm sure. Screenshot incoming.
20:13 hmmmm are you using a custom texture pack
20:14 casimir http://screenshot.ru/upload/images/201​5/03/23/screenshot_12123900148dad8.png
20:15 hmmmm could you give a screenshot of the same scene with texture_clean_transparent = false?
20:15 hmmmm also what video card do you have?
20:17 casimir Ok, with this setting they look how they are supposed to. Is it new?
20:17 est31 VanessaE, you there?
20:17 hmmmm yeah it's new
20:17 hmmmm you weren't supposed to see any difference unless you had some kind of filtering enabled
20:18 hmmmm also can you give a backtrace of the crafting crash?
20:18 hmmmm as far as the last thing you mentioned:  i saw you are using 0.5.0-dev, not the master branch
20:18 hmmmm this is fixed in the master branch
20:19 kilbith casimir, no-fancy leaves disable the alpha channel in the texture, now you no longer see the odd black background on them
20:20 est31 VanessaE, I have bisected the issue you had concerns about, and it is 1b2f64473ed4f222d3b7f02df853730d4382105e.
20:20 est31 (the move stuff from craft field to inventory and back one earlier today)
20:21 casimir thank you hmmmm
20:21 est31 s/it is/its caused by/
20:22 casimir kilbith, I use a dark green background for that reason, and that looks much better.
20:23 kilbith well, now instead of having the patterns + the plain background on them, the leaves are just mixed
20:23 casimir About the crash, I have nothing in my logs.
20:23 MinetestForFun_ joined #minetest-dev
20:28 shadowzone joined #minetest-dev
20:35 est31 VanessaE, see #2544
20:35 ShadowBot https://github.com/minetest/minetest/issues/2544 -- Moving items into crafing grid and back got glitchy (regression) on dreambuilder
20:38 Warr1024 we probably never tested some of the filtering with non-fancy leaves because it doesn't really seem to make much sense to have fancy everything EXCEPT leaves...
20:38 est31 btw the optimisation commits that were merged recently are only about the other direction: output -> input
20:38 Warr1024 how are fancy leaves implemented?  Are they part of the engine, or part of _game?
20:39 Warr1024 seems like it would have been better to actually use a separate texture for leaves when non-fancy...
20:40 est31 my suspicion on 2544 is though that it only exposes a deeper issue. I had similar problems with pipeworks sorttube buttons already. there is even a feature request issue by me...
20:41 Ritchie joined #minetest-dev
20:45 Robert_Zenz joined #minetest-dev
20:54 Hunterz joined #minetest-dev
20:59 Hunterz joined #minetest-dev
20:59 paramat joined #minetest-dev
21:00 Hunterz left #minetest-dev
21:02 paramat damage flash when falling or underwater, when damage is disabled, is not fixed yet
21:03 paramat anyone know why my fork of master often says 0.5dev in the corner of the screen? i only use master branch
21:04 paramat version detection seems buggy
21:07 hmmmm is casmir using your fork???
21:08 paramat nope
21:08 hmmmm hmm
21:08 hmmmm anyway, about 2533
21:08 paramat i suspect casimir's screenshot is actually master branch, but displays 0.5dev on the screen as mine does
21:09 hmmmm there definitely is value in keeping area parameters for generate_decorations and so on
21:09 hmmmm so when you added it, people had to change their code if they used it already, right?
21:09 shadowzone joined #minetest-dev
21:09 hmmmm changing it back would be even worse now
21:09 paramat yes
21:09 hmmmm why not make it an optional parameter
21:10 hmmmm i'm still not sure what would make the most sense in terms of "do things inside a voxelmanip" apis
21:10 hmmmm it's very likely that whenever somebody is going to a). calculate lighting, b). update liquids, c). place ores and decorations they're probably doing it from the context of a mapgen voxelmanip
21:11 paramat i only know of one modder using generate_ores/decos, changing back would make their original code work, so better for them
21:11 hmmmm hrmmm
21:11 paramat but with minp, maxp this time as it should be
21:12 hmmmm i think we should make the two pmin/pmax parameters optional
21:12 hmmmm what about you?
21:12 hmmmm and getBlockSeed should use pmin as its position
21:12 paramat ..and default to minp/maxp
21:12 hmmmm right
21:13 hmmmm well minp/max would default to the inner edge of a mapgen voxelmanip
21:13 hmmmm but this way if somebody has a voxelmanip that isn't from the mapgen, they're able to make it work
21:13 paramat i'm sorta neutral but can't see a use for p1/p2
21:13 hmmmm well like i just said
21:13 hmmmm if somebody is decorating from within a non-mapgen voxelmanip
21:13 hmmmm then having a p1/p2 would be absolutely necessary
21:13 paramat ah
21:14 paramat okay i'll make it optional p1/p2
21:14 hmmmm you might be wondering why anybody would generate ores and decorations in a non-mapgen voxelmanip
21:14 hmmmm i am too, but you never know until it happens
21:14 paramat yeah
21:14 hmmmm things get used in very interesting and innovative ways
21:15 paramat and these optional p1/p2 should be checked for validity and sorted
21:15 hmmmm heh I think I just thought of a potential use for modifying hud in an on_generate callback
21:15 hmmmm well
21:15 hmmmm we'll change all the push_v3s16s to check_v3s16s in a different commit
21:16 paramat yeah, as i don't know how to check validity
21:16 paramat i'll just sort
21:16 paramat #2543
21:16 ShadowBot https://github.com/minetest/minetest/issues/2543 -- Mgv6: Use heightmap in placeTreesAndJungleGrass() by paramat
21:17 hmmmm v3s16 pmin = lua_istable(L, 2) ? read_v3s16(L, 2) : mg.vm->m_area.MinEdge + v3s16(1,1,1) * MAP_BLOCKSIZE;
21:17 hmmmm like that
21:17 paramat ah okay
21:18 hmmmm 2543 looks good
21:19 paramat oh and blockseed should be either p1 or default minp?
21:19 hmmmm just make it minp
21:19 hmmmm erm, p1 after sorting
21:19 hmmmm it should be "the minimum coordinate that generation is going to happen at"
21:20 paramat ah okay
21:22 roniz joined #minetest-dev
21:22 DFeniks joined #minetest-dev
21:26 VanessaE est31: I am here now.  I see the issue you filed.
21:26 * VanessaE sighs
21:27 est31 as I said it might have only exposed an already existing issue better I'm not sure.
21:27 VanessaE possible
21:30 paramat hmmmmm when you left c55 made me mapgen manager, but i said 'only while hmmmmm is gone', and your name remains on the wiki. i'm not too bothered either way but would it be useful to share the position such that i can reduce your workload by doing the simpler stuff? not sure it makes much difference anyway as i need your approval for PRs
21:30 VanessaE that needs added as a line item to #2524 then
21:30 ShadowBot https://github.com/minetest/minetest/issues/2524 -- Issues with new network code
21:31 hmmmm it doesn't matter
21:31 VanessaE or at least referenced.
21:31 hmmmm what matters is the code
21:39 jin_xi non mapgen vmanip is still necessary if you want to do anything fancy, ie lua generated, unless you do the whole mapgen in lua
21:44 paramat yep
21:48 VanessaE est31: come to think of it, even *placing* an object seems kinda laggy now.
21:48 VanessaE I don't recall e.g. pipeworks pipes having a visible lag between placement and the autorouter kicking in.
21:50 est31 there is such a lag
21:50 est31 I had it for technic cables on VE-S enough times
21:51 est31 ofc only when the server is under load too
21:51 VanessaE yeah but in singleplayer, in a test world that's totally idle?
21:51 paramat now pushing 2543, will notify when done
21:53 est31 is that the same issue btw?
21:53 ElectronLibre left #minetest-dev
21:53 est31 could you confirm that the commit from my report introduces the placing lag?
21:56 VanessaE sure, lemme check
22:00 paramat push complete
22:00 VanessaE I've rolled back to 038d3a31 (one commit before 1b2f644), and am not seeing nearly as much placement delay or glitchiness now.
22:00 VanessaE s/glitchiness/crafting grid glitchiness/
22:00 VanessaE so that should be enough to confirm your report
22:04 VanessaE added my comments to 2544
22:04 hmmmm well
22:04 hmmmm it seems to be a pretty big problem
22:05 hmmmm i think maybe the offending commit should be reverted until it's solved
22:05 hmmmm as for the clean_transparent_textures, we can solve that problem by setting it to disabled by default
22:06 hmmmm i tested these commits too and they seemed okay at the time :(
22:50 devmarth joined #minetest-dev
22:55 paramat left #minetest-dev
23:33 devmarth joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext