Time  Nick       Message
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
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
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.
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/2015-03-22/?msg=34774874&page=3
03:54 est31      begin of discussion: https://botbot.me/freenode/fdroid/2015-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 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/commit/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/commit/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/minetest/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 WarrTab    Meh, maybe I'll whip up a pr
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 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: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.
10:10 est31      finally, minetest is also available in the f-droid app store! https://f-droid.org/repository/browse/?fdfilter=mine&fdid=net.minetest.minetest
10:24 est31      and the proper URL is https://f-droid.org/repository/browse/?fdid=net.minetest.minetest
10:27 Calinou    they have an IRC btw, #fdroid
12:57 Zeno`      kinda quiet
13:26 Zeno`      nrzkt, are you awake?
13:26 est31      https://github.com/minetest/minetest/pull/2540#issuecomment-84995376
13:26 est31      seems so
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:54 Zeno`      I might have a break as well. I'm very confused atm lol
14:46 nrzkt      PilzAdam: how signs_lib generate their names ?
14:48 PilzAdam   https://github.com/VanessaE/homedecor_modpack/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/minetest/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: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:22 * VanessaE wanders in
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/master/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: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/master/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 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: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 Zeno`      http://dpaste.com/1R891VG
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
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/2015/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: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...
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 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: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 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 :(