--- Log opened Sat Oct 15 00:00:44 2016
20161015 00:08:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161015 00:10:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161015 00:15:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20161015 00:36:36-!- stikonas_ is now known as stikonas
20161015 00:38:20-!- Bonobo [~Bonobo@2001:44b8:254:3200:c199:223f:8b52:dc5d] has joined #wesnoth-dev
20161015 00:38:41-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161015 00:41:41-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds]
20161015 00:41:41-!- wedge010 is now known as wedge009
20161015 00:56:40-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161015 00:58:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 258 seconds]
20161015 01:08:39-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161015 01:08:49-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161015 01:10:54-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161015 01:12:06-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161015 01:14:36-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161015 01:23:14-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161015 01:45:15-!- iceiceice [~chris@23-31-228-41-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20161015 01:45:15-!- iceiceice [~chris@23-31-228-41-static.hfc.comcastbusiness.net] has quit [Changing host]
20161015 01:45:15-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161015 01:45:26< iceiceice> hi,
20161015 01:45:27< iceiceice> in response to past messages regards SDL_savepng
20161015 01:45:51< iceiceice> i added SDL_savepng b/c it was the simplest way I could see to save a png
20161015 01:45:57< iceiceice> the original source is on github
20161015 01:46:19< iceiceice> it is distributed as a C library, like the other SDL_image libs
20161015 01:46:23< iceiceice> however, it is about 100 lines of code or something
20161015 01:46:27< iceiceice> and it all is valid C++ also
20161015 01:46:37< iceiceice> so i just brought it into source tree and changed extension to C++
20161015 01:47:03< iceiceice> we similarly did that with lua itself
20161015 01:47:16< iceiceice> which is significantly more suspect imo
20161015 01:47:30< iceiceice> i remember seeing that people later thought it should be .c,
20161015 01:47:35< iceiceice> that's fine do it however you like
20161015 01:48:14< iceiceice> but if you think it's a bug to label it as .cpp instead of .c, then lua is a bigger fish for you to fry than sdl_savepng, IMO
20161015 01:48:38< iceiceice> tad_carlucci, shadowm, loonycyborg: ^
20161015 01:48:46< iceiceice> (don't remember who else commented on this)
20161015 01:51:56< iceiceice> Soliton: thanks for info about the query metrics
20161015 01:53:47< iceiceice> i think i'm caught up on logs now, if someone pinged me and i missed it, sorry and please try again
20161015 01:54:46-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161015 01:58:05-!- gfgtdf_ [~chatzilla@x4e32b350.dyn.telefonica.de] has joined #wesnoth-dev
20161015 01:59:50-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Quit: Ex-Chat]
20161015 02:00:18-!- gfgtdf [~chatzilla@x4e36a4df.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161015 02:00:30-!- gfgtdf_ is now known as gfgtdf
20161015 02:00:40-!- iceiceice [~chris@23-31-228-41-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20161015 02:00:40-!- iceiceice [~chris@23-31-228-41-static.hfc.comcastbusiness.net] has quit [Changing host]
20161015 02:00:40-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161015 02:00:52< iceiceice> 20161006 07:48:35< Aginor> I'm having a very close look at utils.cpp:blit_surface, there's some rather odd alpha blending going on there that I'm not recognising
20161015 02:01:13< iceiceice> Aginor: fwiw there were a few instances of alpha blending that were basically implemented incorrectly that i found in image.cpp two years ago
20161015 02:01:24< iceiceice> around the time that i itnegrated xbrz and looked at code related to that
20161015 02:02:04< iceiceice> there was some wierd thing where it was using alpha for like a threshold test and not actually doing alpha blending as it is traditionally defined
20161015 02:02:29< iceiceice> i think you can still enable the old way with one of the legacy image stretching modes
20161015 02:02:37< iceiceice> but i basically regard it as defective
20161015 02:02:54< iceiceice> and there were code comments to the effect that they weren'thappy with it because it made skeleton archer bowstrings look bad
20161015 02:03:26< iceiceice> so if you see some alpha blending code that doesn't make sense, it's more likely that it's broken imo than that you are not efficiently experienced to understand it
20161015 02:03:37< iceiceice> *not sufficiently experienced to understand it
20161015 02:03:49< iceiceice> bb for real this time
20161015 02:03:51-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Client Quit]
20161015 02:24:19< shadowm> The difference between PNG thingy and Lua is that the former doesn't call code that throws exceptions.
20161015 02:28:31< vultraz> [03:02:47]	celticminstrel	They might make sense if tooltips always appeared to the right of what they apply to, but that's not the case.
20161015 02:28:33< vultraz> [03:03:10]	celticminstrel	Also, tooltip placement was broken at some point.
20161015 02:28:37< vultraz> i dont think so and what do you mean
20161015 02:32:59< vultraz> anddd I missed mordante again
20161015 02:33:15< vultraz> and tad too
20161015 02:43:22-!- gfgtdf [~chatzilla@x4e32b350.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161015 02:54:51-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has joined #wesnoth-dev
20161015 02:54:51-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has quit [Changing host]
20161015 02:54:51-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161015 02:55:29< iceiceice> shadowm: if that's the issue, an alternative would be to keep lua as C and use -fexceptions gcc flag
20161015 02:57:57< iceiceice> i dont think theres a reason to change it, if lua is working when compiled as c++ then that's probably simpler and enables more optimizations
20161015 02:59:27< iceiceice> i thought the issue was just that it's easier to convince most build systems to compile it as c++ if its labeled .cpp
20161015 03:13:06-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 250 seconds]
20161015 03:24:32< vultraz> iceiceice: the problem is what is the correct blending code
20161015 03:24:44< iceiceice> whats the code look like?
20161015 03:24:53< vultraz> iceiceice: a simple SDL_BlitSurface isn't working for text
20161015 03:25:03< vultraz> it needs to use the custom blit function
20161015 03:25:07< iceiceice> hmmm
20161015 03:25:26< vultraz> https://github.com/wesnoth/wesnoth/blob/master/src/sdl/utils.cpp#L2230
20161015 03:26:20< vultraz> if we use the sdl blit, text looks like absolute shit.
20161015 03:26:33< vultraz> we think there might be something off here https://github.com/wesnoth/wesnoth/blob/master/src/text.cpp#L696
20161015 03:26:39< vultraz> where alpha is 'decoded'
20161015 03:26:46< vultraz> but can't figure it out
20161015 03:34:04< vultraz> and there's one other case of blit_surface with images in gui2 but doesn't seem to do alpha right
20161015 03:34:13< vultraz> probably pre vs post multplied alpha or something
20161015 03:34:15< vultraz> idk
20161015 03:37:10< vultraz> iceiceice: thoughts?
20161015 03:37:18< iceiceice> let me have a look at it
20161015 03:37:43< iceiceice> going to take me a few minutes :D
20161015 03:42:57< iceiceice> vultraz, i wasn't aware that wesnoth had any premultiplied alpha
20161015 03:43:06< vultraz> i have no idea :P
20161015 03:43:25< iceiceice> i see
20161015 03:43:38< iceiceice> so the code comment says cairo uses that but SDL doesn't
20161015 03:43:39< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/text.cpp#L757
20161015 03:45:10< iceiceice> hmm this code is pretty confusing
20161015 03:45:13< iceiceice> code comment at line 757 suggests,
20161015 03:45:20< iceiceice> we need to convert from non-premultiplied alpha to premultiplied alpha
20161015 03:45:37< iceiceice> however, `decode_pixel` comments suggest that it converts premultiplied alpha to non-premultiplied alpha
20161015 03:46:13< iceiceice> well maybe that makes sense i guss
20161015 03:46:19< iceiceice> i guess we are getting an image from cairo
20161015 03:47:02< iceiceice> this is a bad idea: "// Assume everything not compiled with gcc to be on a little endian platform."
20161015 03:47:12< iceiceice> there are better ways to do that
20161015 03:47:32< iceiceice> also it shouldn't matter i think
20161015 03:47:49< iceiceice> endian does not affect RGBA byte order, or it shouldn't unless cairo says so for some reason
20161015 03:49:45< shadowm> iceiceice: I have no idea, I'm just saying that Lua needs to be compiled as C++ and PNG thingy doesn't.
20161015 03:50:16< shadowm> You people can draw your own conclusions from there.
20161015 03:50:20< iceiceice> yah fair enough
20161015 03:50:39< iceiceice> i thought it was simpler if the png thingy is also though
20161015 03:51:18< shadowm> I'd tend to agree with that, but it seems people opted for the more paranoid route recently.
20161015 03:52:33< vultraz> iceiceice: so can that endian conditional be removed?
20161015 03:53:00< shadowm> I suspect the Debian packagers would prefer if you didn't.
20161015 03:53:26< iceiceice> vultraz, i would assume that it's totally broken if it triggers
20161015 03:53:42< iceiceice> wesnoth project should have like, one consistent way of detecting endian
20161015 03:53:46< iceiceice> and use that way everywhere
20161015 03:53:57< iceiceice> it's only supposed to be important for like, network code
20161015 03:54:00< iceiceice> possibly save files
20161015 03:54:10< vultraz> well, I'll leave that up to someone more skilled.
20161015 03:54:21< iceiceice> usually hteres a function like htons or something
20161015 03:54:25< shadowm> Save files are written in a platform-agnostic format.
20161015 03:54:28< iceiceice> that converts from local byte order to network byte order
20161015 03:54:32< iceiceice> yeah i guess thats right
20161015 03:54:39< iceiceice> vultraz: the basic issue is that,
20161015 03:54:50< iceiceice> in C++ the order of the bytes of somethin glike `int` are unspecified
20161015 03:54:54< iceiceice> also in C
20161015 03:55:09< iceiceice> and on some platforms its 0123 and on others its 2301
20161015 03:55:16< iceiceice> (possibly messed that up :D)
20161015 03:55:37< iceiceice> for an array it's always in correct order
20161015 03:55:42< iceiceice> like if you have char[4]
20161015 03:55:50< iceiceice> they always have the order 0123 no matter where you are
20161015 03:56:04< iceiceice> the endian can only be noticed if you are like, casting char[] to int[] or something
20161015 03:56:32< vultraz> so sounds like it can be removed 
20161015 03:56:37< iceiceice> in RGBA you usually represent colors using char
20161015 03:56:41< iceiceice> or maybe i guess int32?
20161015 03:57:16< iceiceice> i guess if it's int32 then endian might matter
20161015 03:57:34< iceiceice> but this function is written to manipulate unsigned char *
20161015 03:57:40< iceiceice> so that's sort of strange
20161015 03:57:45< iceiceice> iirc most of the code in wesnoth used int32
20161015 03:58:16< iceiceice> so probly i guess the fix is to factor out the functions using `unsigned char *`
20161015 03:58:32< iceiceice> so that we use one consistent way of doing RGBA
20161015 03:58:36< iceiceice> and then endian should be irrelevant
20161015 03:58:44< vultraz> but will that have any effect on the actual rendering
20161015 04:01:34< iceiceice> if this endian thing was wrong
20161015 04:01:42< iceiceice> it would mean that alpha channel is switched for red channel
20161015 04:01:49< iceiceice> so it would cause crazy visual artifacts
20161015 04:02:13< iceiceice> and idk how reasonable the assumption that "if we are using GCC and __BIG_ENDIAN__ is not defined then it is little endian"
20161015 04:02:21< iceiceice> frankly that sounds kind of retarded
20161015 04:02:35< iceiceice> it probably would make it hellish to port this game to a phone or something
20161015 04:02:58< vultraz> we want RGBA right
20161015 04:03:03< iceiceice> yah everything is rgba
20161015 04:03:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161015 04:03:21< vultraz> (technically there's some code in wesnoth using ARGB, I think...()
20161015 04:03:25< iceiceice> hmmmm
20161015 04:03:31< iceiceice> ok, will keep an eye out
20161015 04:05:45< vultraz> but yeah, making alpha always p[3] doesn't fix it
20161015 04:07:01< vultraz> (for the record, this is whatit looks like https://drive.google.com/file/d/0B-mR9s8FduLLTG9aSk5DVlpKSkU/view?usp=sharing)
20161015 04:07:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 258 seconds]
20161015 04:08:13< vultraz> (for some reason, text on buttons is the only place it looks right)
20161015 04:08:35< iceiceice> hmmm
20161015 04:08:43< iceiceice> i wonder if cairo is actually not giving premultiplied alpha?
20161015 04:08:45< vultraz> (this is using sdl blit not blit surface)
20161015 04:09:54< vultraz> iceiceice: it looks even worse without calling decode_pixel https://drive.google.com/file/d/0B-mR9s8FduLLVUp5ckZoNS0wTWc/view?usp=sharing
20161015 04:09:59< vultraz> and buttons look bad then too
20161015 04:10:33< iceiceice> is this on every platform?
20161015 04:10:35< iceiceice> or only some platforms?
20161015 04:11:00< vultraz> dunno
20161015 04:12:25< iceiceice> is that on current master, or some branch?
20161015 04:12:56< vultraz> master, with text rendering changed to use sdl_blit
20161015 04:13:32< vultraz> https://github.com/wesnoth/wesnoth/blob/master/src/gui/core/canvas.cpp#L1397
20161015 04:13:51< vultraz> just changing that to sdl_blit immediately shows the issue.
20161015 04:14:06< vultraz> (also what's memset)
20161015 04:14:21< iceiceice> is blit_surface used anywhere else?
20161015 04:14:41< iceiceice> memset just writes a single char to each cell of an array of char
20161015 04:15:02< vultraz> blit_surface is used in 2 other places in that file
20161015 04:15:15< iceiceice> is your goal to elminate blit_surface?
20161015 04:15:25< vultraz> (and one place in gui1 but ignore that, it's only there bc i had to revert something and that use willbe removed soon anyway)
20161015 04:15:27< vultraz> yes
20161015 04:15:31< vultraz> ive gotten most cases
20161015 04:16:46< iceiceice> so blit_surface says "sdl_blit has problems with blitting partly transparent surfaces so ..."
20161015 04:16:57< iceiceice> is the goal to fix sdl_blit? or you just think this wasn't an issue
20161015 04:17:14< vultraz> sdl_blit is an inline wrapper for SDL_BlitSurface
20161015 04:17:30< vultraz> so unless you propose doing something to SDL itself.. :P
20161015 04:19:04< iceiceice> i see
20161015 04:19:24< vultraz> for the record
20161015 04:19:25< iceiceice> vultraz, idk why this code is using memset
20161015 04:19:44< vultraz> this problem does go away if you set the blend mode to NONE
20161015 04:19:49< vultraz> temporarily
20161015 04:19:53< vultraz> but that's not the right "fix"
20161015 04:19:59< iceiceice> is that an SDL option?
20161015 04:20:10< vultraz> SDL_SetSurfaceBlendMode
20161015 04:20:22< iceiceice> what is it currently?
20161015 04:20:23< vultraz> but that's not the right fix since it erases button backgrounds
20161015 04:20:30< vultraz> default is BLEND i think
20161015 04:20:34< iceiceice> ok
20161015 04:20:38< iceiceice> vultraz, this code
20161015 04:20:39< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/text.cpp#L774
20161015 04:20:43< iceiceice> this is super ugly imo
20161015 04:20:49< iceiceice> if you find yourself writing stuff like this
20161015 04:20:56< iceiceice> probly better off to just use std::vector<char>
20161015 04:21:33< vultraz> or just uint32_t?
20161015 04:21:40< iceiceice> yah maybe
20161015 04:21:47< vultraz> though i can't change that myself
20161015 04:21:50< iceiceice> whatever type surface_.assign is expecting
20161015 04:22:03< vultraz> since i still don't understand bitshifts enough to know how to get the individual elements from a uint32_t
20161015 04:22:03< iceiceice> at this line
20161015 04:22:04< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/text.cpp#L779
20161015 04:22:10< iceiceice> it is deleting this buffer every time
20161015 04:22:22< iceiceice> but if you just call resize, it might not have to reallocate it
20161015 04:23:20< vultraz> surface.assign expects a surface or sdl_surface
20161015 04:23:30< vultraz> (surface is a wrapper class around sdl_surface)
20161015 04:26:46< iceiceice> vultraz, at text.cpp line 767
20161015 04:26:54< iceiceice> might be better to try SDL_CreateRGBSurfaceWithFormatFrom
20161015 04:27:03< iceiceice> and explicitly specify what surface type we want
20161015 04:27:34< vultraz> That;s in 2.0.5 :/
20161015 04:28:40< iceiceice> hmmm
20161015 04:29:26< vultraz> ie, not out yet
20161015 04:29:49< vultraz> maybe you could rewrite this surface_buffer stuff since it looks rather inelegant.
20161015 04:31:01< iceiceice> yah
20161015 04:35:18< iceiceice> vultraz, i wonder why we are doing this in ttext constructor:
20161015 04:35:19< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/text.cpp#L93
20161015 04:35:36< vultraz> I have no idea
20161015 04:35:54< vultraz> i don't understand pango/cairo
20161015 04:35:56< vultraz> much
20161015 04:36:14< iceiceice> hmm maybe its not that unusual to have lots of pango contexts
20161015 05:21:15-!- j [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has joined #wesnoth-dev
20161015 05:21:37-!- j is now known as Guest40340
20161015 05:36:19-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds]
20161015 05:36:24< iceiceice> vultraz, do you mind if i split up this file into more files?
20161015 05:40:52-!- Kwandulin [~Miranda@p200300760F2C71A43C37DEEC5E52028B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161015 05:43:56< vultraz> iceiceice: nah, go ahead
20161015 05:48:42< celticminstrel> [Oct 14@10:28:32pm] vultraz: [03:02:47]	celticminstrel	They might make sense if tooltips always appeared to the right of what they apply to, but that's not the case.
20161015 05:48:43< celticminstrel> [Oct 14@10:28:33pm] vultraz: [03:03:10]	celticminstrel	Also, tooltip placement was broken at some point.
20161015 05:48:44< celticminstrel> [Oct 14@10:28:38pm] vultraz: i dont think so and what do you mean
20161015 05:48:45< celticminstrel> 1. You changed the tooltip design to have a thick gold border on the left rather than a thin gold border all around. I don't think that makes sense unless the tooltip always floats to the right of the thing it's describing. 2. You broke tooltip placement - in the multiplayer select dialog, the last tooltip appears at the top left of the screen instead of by the mouse. 3. I personally liked the old tooltips better aesthetically, as w
20161015 05:49:26< celticminstrel> Well. Maybe it wasn't you who broke tooltip placement. I dunno.
20161015 05:50:00< vultraz> mp select dialog?
20161015 05:50:16< celticminstrel> The one that first appears when you click "Multiplayer".
20161015 05:50:30< vultraz> what res?
20161015 05:50:36< celticminstrel> 800x600, of course
20161015 05:51:08< vultraz> yeah that wasn't me
20161015 05:51:36< celticminstrel> But the new tooltip design was.
20161015 05:51:50< vultraz> yes
20161015 05:51:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161015 05:51:53< vultraz> it's a great improvement
20161015 05:52:19< celticminstrel> Not really.
20161015 05:52:24< celticminstrel> It doesn't make sense.
20161015 05:52:32< celticminstrel> Why is there a line on the left edge?
20161015 05:52:38< vultraz> highlight
20161015 05:52:50< celticminstrel> But it doesn't really make sense for it to be there.
20161015 05:52:58< vultraz> it lends elegant asymmetry 
20161015 05:53:12< celticminstrel> It's not the asymmetry that's the problem.
20161015 05:54:25-!- irker280 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161015 05:54:25< irker280> wesnoth: Chris Beck wesnoth:master 683d517d7e7b / src/ (text.cpp text.hpp): remove unnecessary includes, boost::noncopyable, add code comments https://github.com/wesnoth/wesnoth/commit/683d517d7e7b77d1fe29da9f650f3dc74ab06ee3
20161015 05:56:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20161015 06:01:54< iceiceice> hmm so let me see if i understand
20161015 06:02:02< iceiceice> font families are stored in translatable strings?
20161015 06:02:19< iceiceice> because, different languages might want to use different fonts for sans serif, monospace, etc. ?
20161015 06:02:34< iceiceice> (see src/font.cpp)
20161015 06:03:15< vultraz> essentially, yes
20161015 06:04:21< vultraz> I know GUI2 (ttext) only needs the family_order and family_order_monospace keys
20161015 06:04:26< vultraz> dunno if it uses order=
20161015 06:04:34< vultraz> (See data/hardwired/fonts.cfg)
20161015 06:04:35< iceiceice> ok
20161015 06:04:41< vultraz> [font] is GUI1 and you can ignore that
20161015 06:13:18< iceiceice> vultraz, the most horrible thing about changing the text code is that it forces a massive recompilation
20161015 06:13:29< vultraz> this is true
20161015 06:13:36< vultraz> try not to edit the header much :P
20161015 06:13:46< iceiceice> i mean it means that like
20161015 06:13:53< iceiceice> we probably should not include so much crap in this header
20161015 06:13:59< iceiceice> like all of pangocairo etc.
20161015 06:14:08< iceiceice> if it is really being used in so many compilation units
20161015 06:15:16< vultraz> i think it's mostly because it's included by the gui2 canvas
20161015 06:15:25< vultraz> and the gui2 canvas is used in a lot of places
20161015 06:15:51< vultraz> but it's possible the header is included in too many places
20161015 06:16:02< iceiceice> hmm ok
20161015 06:16:42< vultraz> ill take a look
20161015 06:16:45< vultraz> see if i can reduce them
20161015 06:17:14< iceiceice> im checking to see if my ccache is working
20161015 06:17:21< iceiceice> i tried emptying the cache b/c i seem to get a lot of cache misses
20161015 06:17:31< vultraz> hm
20161015 06:17:39< vultraz> actually it's only included in cpp files
20161015 06:17:45< vultraz> so why does it trigger such a big rebuild :|
20161015 06:18:22< celticminstrel> Because it's included in a lot of cpp files, maybe?
20161015 06:18:33< vultraz> 12
20161015 06:18:48< vultraz> that shouldn't trigger a 10 minute rebuild
20161015 06:19:26< celticminstrel> Time isn't really the right way of describing it.
20161015 06:19:53-!- JyrkiVesterinen [~JyrkiVest@87-100-176-54.bb.dnainternet.fi] has joined #wesnoth-dev
20161015 06:25:14-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161015 06:30:05-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161015 06:31:02< irker280> wesnoth: Chris Beck wesnoth:master df8f42c26d2e / src/ (font.cpp font.hpp): add code comments, fixup some pre C++11 code https://github.com/wesnoth/wesnoth/commit/df8f42c26d2e44f08f2fa8175ebd33fff41f860a
20161015 06:33:47< JyrkiVesterinen> 20161015 04:02:35< iceiceice> it probably would make it hellish to port this game to a phone or something
20161015 06:33:59< JyrkiVesterinen> The ARM architecture uses little-endian by default.
20161015 06:34:26< JyrkiVesterinen> Thus, both PC and phones are little-endian. Big-endian systems are extremely rare today.
20161015 06:36:38< vultraz> iceiceice: for the record, we intend to drop the SDL_TTF path eventually
20161015 06:36:41< vultraz> once gui1 is gone
20161015 06:37:09< iceiceice> JyrkiVesterinen, ok but in a sane project, there is a simple compiler flag to select big endian or little endian
20161015 06:37:13-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161015 06:37:14-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161015 06:37:55< iceiceice> using gcc has absolutely nothing to do with endian
20161015 06:37:59< iceiceice> so this line...
20161015 06:37:59< iceiceice> / Assume everything not compiled with gcc to be on a little endian platform.
20161015 06:37:59< iceiceice> #if defined(__GNUC__) && defined(__BIG_ENDIAN__)
20161015 06:38:13< JyrkiVesterinen> IMHO, completely dropping big-endian support (by failing to compile on big endian) would be a sane option as well.
20161015 06:38:27< iceiceice> until quite recently we targetted power pc also
20161015 06:39:16< iceiceice> JyrkiVesterinen, there's no reason to drop support for big endian
20161015 06:39:52< JyrkiVesterinen> It's hard to get anyone to test if the code works correctly on big endian.
20161015 06:40:14< JyrkiVesterinen> "Coding in the dark", without being able to test the code, is very hard.
20161015 06:40:16< iceiceice> nah there are people running ancient OS X machines who play wesnoth,
20161015 06:40:21< iceiceice> they post on forums regularly
20161015 06:40:27< iceiceice> idk maybe they finally got new machines
20161015 06:40:47< iceiceice> even if you don't care to test it,
20161015 06:40:56< JyrkiVesterinen> OK, I didn't know that.
20161015 06:41:08< iceiceice> i mean it should be easy to fix such bugs anyways
20161015 06:41:16< iceiceice> i never heard ofa C++ project that doesn't support one kind of endian
20161015 06:41:27< celticminstrel> Actually, we've basically dropped PPC support for OSX.
20161015 06:41:54< celticminstrel> 10.7 minimum now.
20161015 06:42:02< iceiceice> the only thing that would make it hard is if instead of doing it properly you test some nonsense preprocessor defines
20161015 06:42:15< iceiceice> and possibly different defines at every location...
20161015 06:43:40< JyrkiVesterinen> Well, programmers can easily end up writing code that depends on some underlying characteristics, and not bother to test that the assumptions hold.
20161015 06:43:44< celticminstrel> On the other hand, I don't know any reason why Wesnoth shouldn't be able to build on a big-endian machine.
20161015 06:44:08< JyrkiVesterinen> For example, here we assume IEEE 754 floating point numbers: https://github.com/wesnoth/wesnoth/blob/master/src/random_new.cpp#L105-L128 (my code)
20161015 06:44:13< celticminstrel> Is there even anything that cares about the endianness? Normally you have to worry about it just for persistance and transport.
20161015 06:45:32< celticminstrel> Is "double" guaranteed to be double precision, by the way? Or only "at least" double precision?
20161015 06:47:36< JyrkiVesterinen> I looked at the standard. No, it's not guaranteed.
20161015 06:47:39< JyrkiVesterinen> "The set of values of the type float is a subset of the set of values of the type double; the set of values
20161015 06:47:39< JyrkiVesterinen> of the type double is a subset of the set of values of the type long double. The value representation of
20161015 06:47:39< JyrkiVesterinen> floating-point types is implementation-defined."
20161015 06:48:06< celticminstrel> I probably would've written that code with division instead of bit trickery though. (Not saying we should, mind you.)
20161015 06:49:37-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161015 06:52:54< Guest40340> we should just remove support for apple products entirely because apple is awful
20161015 06:56:26-!- Kwandulin [~Miranda@p200300760F2C71A43C37DEEC5E52028B.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20161015 06:57:03-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161015 06:59:40-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161015 07:02:12-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Client Quit]
20161015 07:07:04-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161015 07:07:33-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161015 07:07:44< iceiceice> JyrkiVesterinen, i don tknow why we do that with the doubles
20161015 07:07:50< iceiceice> it's probably faster to just write exactly what we want
20161015 07:07:57< iceiceice> and let the optimizer screw around iwth the bit shifting
20161015 07:08:04-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Client Quit]
20161015 07:08:20< iceiceice> JyrkiVesterinen, unless something changed while i was gone, wesnoth was supposed to be cross-platform
20161015 07:08:27< JyrkiVesterinen> I figured that getting the random double generation exactly right was *easier* with bit shifting.
20161015 07:08:28< iceiceice> and we don't state any assumptions about endianness, floating point, whatever
20161015 07:09:06< iceiceice> JyrkiVesterinen, i think its probably easiest to take uint32 or uint64, whatever the generator is producing,
20161015 07:09:09< iceiceice> static cast it to double,
20161015 07:09:14< JyrkiVesterinen> It is important that the range of possible doubles is [0, 1[. Zero must be a possible return value. One must never be returned.
20161015 07:09:15< iceiceice> then divide by uint32_t max 
20161015 07:09:44< iceiceice> yah ok but odds of exactly one are very small
20161015 07:09:45< JyrkiVesterinen> I was afraid that with division I might get an off-by-one error, and a wrong range of return values.
20161015 07:09:51< iceiceice> you could divide by uint32_t max + 1 or something
20161015 07:10:01< iceiceice> i think the bias caused by such an off-by-one erorr is very low
20161015 07:10:18< iceiceice> you could also like, look at what other people do
20161015 07:10:32< iceiceice> i think i asked a question like this on code review once actually
20161015 07:10:33< JyrkiVesterinen> I wasn't sure that I would get it right with division.
20161015 07:11:05< iceiceice> JyrkiVesterinen, http://codereview.stackexchange.com/questions/122497/portably-generate-uniformly-random-floats-from-mt19937-output
20161015 07:11:05< JyrkiVesterinen> A wrong range of return values would potentially cause problems other than bias, too.
20161015 07:11:44< iceiceice> JyrkiVesterinen, i ultimately looked in the mt19937 paper for the reference implementation, which also just uses division it turns out
20161015 07:12:39< JyrkiVesterinen> In addition, AFAIK pretty much all hardware used today uses IEEE 754 floats.
20161015 07:13:10< iceiceice> i don't remember if the pandora used ieee floats
20161015 07:13:42< iceiceice> i mean look, if people want to make such assumptions, should state them int he build instructions
20161015 07:13:51< iceiceice> or make some kind of test to put in the build system
20161015 07:13:53< JyrkiVesterinen> Pandora is no longer supported.
20161015 07:14:02< iceiceice> "you do not have IEEE floats, build will be screwed"
20161015 07:14:31< iceiceice> if you just silently make a bunch of wierd architecture assumptions that aren't stated anywhere in docs or configuration, that's just buggy code
20161015 07:14:34< iceiceice> imo
20161015 07:15:11< iceiceice> and if people come to realize that every source file is making different such assumptions,
20161015 07:15:16< iceiceice> they will rapidly lose interest in porting the game
20161015 07:15:32< JyrkiVesterinen> Hmm, adding some kind of test would indeed make sense. Added to my todo list.
20161015 07:16:31< JyrkiVesterinen> Also, neither IEEE 754 nor little-endian are unreasonable assumptions in my opinion. They are both virtually universal.
20161015 07:19:17< iceiceice> ok but there should be like, a project wide policy, not, each dev forms their own opinions about what architectures matter
20161015 07:19:43< vultraz> that's the case in a lot of areas
20161015 07:20:06< iceiceice> T_T
20161015 07:24:34< vultraz> btw, i plan on refactoring the STYLE_* stuff
20161015 07:25:20< iceiceice> ok
20161015 07:25:29< iceiceice> i am planning to move a bunch of this font stuff into a src/font folder
20161015 07:25:33< iceiceice> and split up into smaller files
20161015 07:31:08-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161015 07:40:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161015 07:45:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20161015 08:05:42-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161015 08:16:52< vultraz> iceiceice: are you splitting text.*cpp or font.*cpp?
20161015 08:17:01< iceiceice> both i guess
20161015 08:17:11< vultraz> iceiceice: because be sure to keep the TTF stuff separate 
20161015 08:17:18< vultraz> so we can remove it eeasily
20161015 08:17:26< iceiceice> yah i'm trying to mark it with comments in header
20161015 08:20:00< iceiceice> whoa sconstruct looks different
20161015 08:20:10< iceiceice> does it glob over src/ directory now or something?
20161015 08:20:42< vultraz> sconstruct or sconsscript
20161015 08:20:44< vultraz> ?
20161015 08:28:14< zookeeper> shadowm, any idea if penta's password can even be reset? i tried through Special:PasswordReset but it won't let me since there's no e-mail address recorded.
20161015 08:29:21< vultraz> zookeeper: shadowm can do it by editing the database
20161015 08:32:43-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161015 08:33:06-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161015 08:33:32-!- Netsplit *.net <-> *.split quits: new_one, esr, pydsigner, prkc, Polsaker, iceiceice
20161015 08:33:32-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit]
20161015 08:33:55-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161015 08:34:19-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit]
20161015 08:34:40-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161015 08:35:06-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit]
20161015 08:35:31-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161015 08:35:54-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit]
20161015 08:36:20-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161015 08:36:42-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit]
20161015 08:38:29-!- prkc [~prkc@46.166.138.134] has joined #wesnoth-dev
20161015 08:51:02-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161015 08:51:02-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has joined #wesnoth-dev
20161015 08:51:02-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20161015 08:51:02-!- Polsaker [~Polsaker@wikimedia/botters.Polsaker] has joined #wesnoth-dev
20161015 09:08:08-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Ping timeout: 260 seconds]
20161015 09:08:35-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161015 09:10:30-!- new_one [~new_one@2604:a880:1:20::22e:d001] has joined #wesnoth-dev
20161015 09:25:00-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161015 09:28:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161015 09:32:50-!- irker280 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161015 09:32:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161015 09:33:15-!- Porusaka [~Polsaker@wikimedia/botters.Polsaker] has joined #wesnoth-dev
20161015 09:37:40-!- Netsplit *.net <-> *.split quits: Polsaker, pydsigner, esr
20161015 09:38:01-!- Netsplit over, joins: pydsigner
20161015 09:45:20-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20161015 09:45:20-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20161015 09:45:20-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20161015 09:56:42< vultraz> iceiceice: i can't actually figure out how ttext (the pango class) loads fonts
20161015 09:56:59< iceiceice> i think it uses font_config
20161015 09:57:04< vultraz> iceiceice: i recently wanted to add loading for the lato font weight variations but i couldn't get the game to load them
20161015 09:57:04< Guest40340> i found bug
20161015 09:57:04< iceiceice> there is a font::manager class
20161015 09:57:14< vultraz> i know pango or cairo has a font description thing
20161015 09:57:16< iceiceice> that includes ashit ton of cairo stuff
20161015 09:57:23< vultraz> hmm
20161015 09:57:26< Guest40340> in wc the bonus labels go over the chat messages
20161015 09:57:29< vultraz> ill have to look at that
20161015 09:57:29< iceiceice> i think its actually in the gui1 file
20161015 09:57:33< iceiceice> vultraz:
20161015 09:57:38< iceiceice> i split it all up in a PR just now
20161015 09:57:45< iceiceice> https://github.com/wesnoth/wesnoth/pull/827
20161015 09:57:46< vultraz> iceiceice: well that's ridiculous so im glad you split it
20161015 09:59:01< iceiceice> vultraz, i think it is happening here:
20161015 09:59:01< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/font.cpp#L393
20161015 09:59:10-!- Kwandulin [~Miranda@p200300760F2C71128C77B020CFF94E5F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161015 09:59:45< vultraz> hmm
20161015 10:00:00< vultraz> it looks like that's saying anything in fonts/ is loaded
20161015 10:01:02< iceiceice> i dont know exactly where cairo and font config are told to be friends with one-another
20161015 10:01:18< iceiceice> but afaict the other place that fonts are loaded is also in that file
20161015 10:01:24< iceiceice> with the "open_font" stuff
20161015 10:01:29< iceiceice> and that is specifically SDL_TTF
20161015 10:01:57< vultraz> blah
20161015 10:02:13< vultraz> i know cairo has a font description thing where it loads the closest font or something
20161015 10:02:25< vultraz> but ic ouldn't get it to use the different weight variation
20161015 10:04:44< vultraz> ill try again after your pr is merged
20161015 10:05:57< iceiceice> yah i might leave it up for a bit
20161015 10:06:01< iceiceice> in case there are problems or something
20161015 10:06:09< iceiceice> or for comments
20161015 10:06:16< iceiceice> im trying to do ttextnow
20161015 10:06:19< iceiceice> ttext now
20161015 10:06:38< vultraz> only comments i have are a few indent problems
20161015 10:06:50< vultraz> and i wish you'd use the , member() format for constructor lists
20161015 10:06:57< vultraz> instead of member(),
20161015 10:11:06-!- JyrkiVesterinen [~JyrkiVest@87-100-176-54.bb.dnainternet.fi] has quit [Quit: .]
20161015 10:11:14< iceiceice> oh
20161015 10:11:20< iceiceice> yah i prefer the , member()
20161015 10:11:32< iceiceice> if it doesnt have that then i think it ddn't originally
20161015 10:11:47< iceiceice> you know that clang-format can fix stuff like that automatically?
20161015 10:19:35< vultraz> i did not
20161015 10:27:11< iceiceice> vultraz, looking in pango thing regarding weights of fonts,
20161015 10:27:19< iceiceice> https://developer.gnome.org/pango/stable/pango-Fonts.html#pango-Fonts.description
20161015 10:27:33< iceiceice> i think if u want different weight, you might need to edit ttext?
20161015 10:27:36< iceiceice> to expose that field?
20161015 10:28:03< vultraz> font description?
20161015 10:28:17< vultraz> or do you mean weight?
20161015 10:28:40< vultraz> because there's already a weight setter
20161015 10:28:42< vultraz> https://developer.gnome.org/pango/stable/pango-Fonts.html#pango-font-description-set-weight
20161015 10:28:46< iceiceice> there is an object here:
20161015 10:28:46< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/text.cpp#L552
20161015 10:28:47< vultraz> and i tried that but the font didnt change
20161015 10:28:57< vultraz> yeah
20161015 10:29:06< iceiceice> it is used here
20161015 10:29:07< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/text.cpp#L601
20161015 10:29:26< vultraz> i had added a flag for thin and used pango_font_description_set_weight(font_, PANGO_WEIGHT_LIGHT);
20161015 10:29:29< vultraz> but it ddn't wor
20161015 10:29:43< vultraz> even when i tested that code was reached
20161015 10:29:44< iceiceice> hmmm ok
20161015 10:30:37< iceiceice> i wonder if theres a good way to get debug info from pango
20161015 10:30:42< iceiceice> maybe can try doing stuff like this?
20161015 10:30:42< iceiceice> pango_font_description_to_string ()
20161015 10:30:47< iceiceice> and dumping it to log
20161015 10:31:56< vultraz> peraps
20161015 10:31:59< vultraz> perhaps
20161015 10:32:08< vultraz> ill try again once your pr is merged and i do some refactoring
20161015 10:32:17< vultraz> i want to separate style and weight
20161015 10:32:26< vultraz> bc in pango they're different
20161015 10:32:34< vultraz> but in sdl_ttf they were the same
20161015 10:33:07< vultraz> and ttext still uses ttf constants
20161015 10:33:16-!- travis-ci [~travis-ci@ec2-54-160-188-238.compute-1.amazonaws.com] has joined #wesnoth-dev
20161015 10:33:17< travis-ci> cbeck88/wesnoth#182 (font_refactor - e3417bd : Chris Beck): The build passed.
20161015 10:33:17< travis-ci> Build details : https://travis-ci.org/cbeck88/wesnoth/builds/167853019
20161015 10:33:18-!- travis-ci [~travis-ci@ec2-54-160-188-238.compute-1.amazonaws.com] has left #wesnoth-dev []
20161015 11:06:54-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20161015 11:11:33-!- gfgtdf [~chatzilla@x4e32b220.dyn.telefonica.de] has joined #wesnoth-dev
20161015 11:15:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161015 11:16:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161015 11:20:05< gfgtdf> iceiceice, shadowm: when removing boost::noncopyable you have to delete the asigment operator aswell not ust the copy ctor.
20161015 11:21:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161015 11:21:28< iceiceice> gfgtdf: i think that's not true, i think the standard says if you delete the copy ctor then assignment operaotr is implicitly deleted
20161015 11:21:34< iceiceice> will look for refernce to be sure
20161015 11:22:49< gfgtdf> iceiceice: i tested on http://cpp.sh/ and thise code http://pastebin.com/h8Vh5iXW complied fine
20161015 11:24:27< iceiceice> yah i guess you are right
20161015 11:49:40-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161015 11:50:16< vultraz> iceiceice: you forgot a few copyright headers
20161015 11:50:49< iceiceice> so i did
20161015 11:50:50< iceiceice> will fix
20161015 12:13:44< iceiceice> ok, going to sleep now
20161015 12:13:54< iceiceice> vultraz: i didn't actually fix the "decode" function, that is next :D
20161015 12:14:06< iceiceice> gnight
20161015 12:14:08-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Quit: Ex-Chat]
20161015 12:15:03-!- louis94 [~~louis94@91.178.242.139] has joined #wesnoth-dev
20161015 12:24:57-!- iwaim [~iwaim@rasteenie.alib.jp] has quit [Ping timeout: 258 seconds]
20161015 12:27:28-!- iwaim [~iwaim@124.146.179.10] has joined #wesnoth-dev
20161015 12:29:59< shadowm> gfgtdf: Good catch, I forgot about it entirely.
20161015 13:10:41-!- Appleman1234 [~Appleman1@KD106154002031.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20161015 13:11:18-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Read error: Connection reset by peer]
20161015 13:12:52-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161015 13:16:12-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 268 seconds]
20161015 13:16:13-!- wedge010 is now known as wedge009
20161015 13:21:22-!- JyrkiVesterinen [~JyrkiVest@87-92-16-107.bb.dnainternet.fi] has joined #wesnoth-dev
20161015 13:22:35-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161015 13:25:31-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161015 13:26:42-!- Bonobo [~Bonobo@2001:44b8:254:3200:c199:223f:8b52:dc5d] has quit [Quit: Leaving]
20161015 13:31:02-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161015 13:32:51-!- Appleman1234 [~Appleman1@KD106154010091.au-net.ne.jp] has joined #wesnoth-dev
20161015 13:38:37< tad_carlucci> vultraz, I have some questions about "error in gui/layout" messages I'm seeing.
20161015 13:41:35< vultraz> yes?
20161015 13:48:27-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161015 13:48:53< tad_carlucci> Ah. When getting Travis/CI to pass, I notices the my other PRs don't show the message, but the Lua upgrade does.
20161015 13:49:14< gfgtdf> tad_carlucci: which erormessage exactly do you mean ?
20161015 13:49:30< tad_carlucci> Getting a link.
20161015 13:50:52< tad_carlucci> https://travis-ci.org/wesnoth/wesnoth/jobs/167745720 starting at bottom, line 3023 
20161015 13:51:53< tad_carlucci> What concerns me is that is seems to only be on the lua upgrade PR. And I get it locally when I 'scons test; ./test'
20161015 13:53:42< gfgtdf> tad_carlucci: hmm line 3023 is '/usr/bin/cmake -E cmake_progress_report /home/travis/build/wesnoth/wesnoth/CMakeFiles ' here
20161015 13:53:45< JyrkiVesterinen> tad_carlucci: It also happens in master, e.g. https://travis-ci.org/wesnoth/wesnoth/jobs/167834550
20161015 13:54:13< JyrkiVesterinen> It has been happening since before I joined the project.
20161015 13:54:28< tad_carlucci> How odd. So it comes and goes?
20161015 13:54:55< JyrkiVesterinen> I recall that the messages appear in all Travis builds.
20161015 13:56:23< gfgtdf> ok after avtivating javascript the line numbers have changed, 
20161015 13:56:32< tad_carlucci> Seemed to me I didn't see in on the clang/cleanup PR which is why it concerned me that it appeared on the Lua upgrade. I'm being hyper about the PR because I'm waiting for the fireworks to begin.
20161015 13:56:34< gfgtdf> tad_carlucci: this ia actuall an assertion failure in 1.12
20161015 13:56:57-!- louis94 [~~louis94@91.178.242.139] has quit [Ping timeout: 252 seconds]
20161015 13:57:00< gfgtdf> tad_carlucci: but since it happens quite often and noone knew how to fix it we made it indo a simple erore message
20161015 13:58:07< tad_carlucci> OK. Well, Travis/CI passes on all my PRs so I'm a happy camper. It did help me debug the Boost patch so I'm glad I worked on it.
20161015 13:58:22< vultraz> can anyone confirm if changing a team in mp staging results in a Widget Not Found error
20161015 13:59:00< gfgtdf> tad_carlucci: it's known that you can trigger this error by defeinin 'imposible' window wml, for example by forcing the same size of an container wigets and one of its childs to have teh same size by using linked groups.
20161015 13:59:11< gfgtdf> vultraz: can buidl wesnot currently sry
20161015 13:59:30< gfgtdf> tad_carlucci: but there are other sitatuons where it happens aswell.
20161015 14:01:19< tad_carlucci> Well, as I said, it's a known issue and Travis/CI passes, so I'm happily waiting developments.
20161015 14:01:27-!- louis94 [~~louis94@91.178.242.139] has joined #wesnoth-dev
20161015 14:04:14< vultraz> well this is odd
20161015 14:04:54< tad_carlucci> vultraz, I was trying to see if I could confirm your question and got this: Segmentation fault (core dumped)
20161015 14:05:18< vultraz> -_-
20161015 14:05:22< vultraz> well, i think i found the fix
20161015 14:05:24< tad_carlucci> Fresh build from sync this AM
20161015 14:05:41< vultraz> the segfault is likely the combobox thing
20161015 14:06:11< tad_carlucci> Changing sides in a random game. 1->2 then 2->1 attempt crashed
20161015 14:06:49-!- Kwandulin [~Miranda@p200300760F2C71128C77B020CFF94E5F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161015 14:08:46-!- irker539 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161015 14:08:47< irker539> wesnoth: Charles Dang wesnoth:master 28a45d001372 / src/gui/dialogs/multiplayer/mp_staging.cpp: MP Staging: fixed Widget Not Found errors after switching teams https://github.com/wesnoth/wesnoth/commit/28a45d001372418a3d00f63b2413747f84f59cbe
20161015 14:08:49< vultraz> that seems to fix the widget not found stuff
20161015 14:08:56< vultraz> not sure exactly why
20161015 14:09:35< tad_carlucci> 20161015 09:03:11 error gui/layout: Failed to fit vertical list to requested rect; expected bottom edge was 27120161015 09:03:11 error gui/layout: , actual bottom edge was 15920161015 09:03:11 error gui/layout:  (top edge is 159)
20161015 14:09:35< tad_carlucci> 20161015 09:03:49 info server: 127.0.0.1	lundberg	created game:	"lundberg’s game" (1).
20161015 14:09:35< tad_carlucci> 20161015 09:03:54 error display: could not open image 'misc/status.png'
20161015 14:10:51< vultraz> since side_tree_map_ isn't really used in any place where one would be getting a grid from it except the network handler which i don't think was the problem..
20161015 14:11:12< vultraz> or perhaps it was some other kind of error
20161015 14:11:26< vultraz> i dunno
20161015 14:11:36< vultraz> don't have the energy to figure out why it happened
20161015 14:11:40< vultraz> but that seems to fix it
20161015 14:13:13< vultraz> tad_carlucci: what is that from?
20161015 14:15:13< tad_carlucci> console log just before the segfault
20161015 14:15:35< tad_carlucci> Creating a random 9p MP game.
20161015 14:15:58< vultraz> blah
20161015 14:16:05< vultraz> resolution?
20161015 14:16:24< tad_carlucci> big 1400 or so. If you need exact I can check
20161015 14:16:30< vultraz> that's fine
20161015 14:17:01< vultraz> anyway, the segfault is likely due to this weird issue with dropdowns where the game crashes if you click and move you mouse away too fast
20161015 14:17:10< vultraz> your*
20161015 14:18:00< tad_carlucci> I'll try slow and fast. But remember it was about normal for me.
20161015 14:20:56-!- Guest40340 [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has quit [Ping timeout: 260 seconds]
20161015 14:22:20< tad_carlucci> 2p random. Clicked on change side for side 1. Clicked away to leave not changed. Crashed when I clicked the drop-down arrow to change side for side 2.
20161015 14:25:12< tad_carlucci> And this is strange .. I was running on a second terminal window and some messages went to the first ... So something is hardcoded?
20161015 14:25:14< matthiakrgr> something like this? http://pastebin.com/TuiajcQz  
20161015 14:26:37< matthiakrgr> bbl
20161015 14:27:55-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161015 14:28:08< tad_carlucci> Oh. I see. wesnothd is still running on that window.
20161015 14:55:25< gfgtdf> vultraz: ^ this looks like tmp_staging::side_tree_map_ contains pointers to already temove trreview_node objects
20161015 14:55:51< gfgtdf> removed*
20161015 15:05:41-!- Kwandulin [~Miranda@p200300760F2C71120429CF15DF73E505.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161015 15:14:43-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Read error: Connection reset by peer]
20161015 15:14:47-!- mkdr0id [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161015 15:15:32< tad_carlucci> pastebin.com/Dqis2HES
20161015 15:17:08-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.]
20161015 15:18:02-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161015 15:19:40-!- mkdr0id [~null@unaffiliated/matthiaskrgr] has quit [Ping timeout: 265 seconds]
20161015 15:21:56-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has quit [Ping timeout: 260 seconds]
20161015 15:35:36-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161015 15:41:48-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Switching to Unix to get some real work done.]
20161015 15:59:03-!- DeFender1031 [~DeFender1@46-116-17-86.bb.netvision.net.il] has joined #wesnoth-dev
20161015 16:18:17-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20161015 16:23:50-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161015 16:24:14< iceiceice> vultraz, regarding this cairo premultiplied alpha thing,
20161015 16:24:34< iceiceice> instead of trying to convert a cairo surface to non-premultiplied alpha,
20161015 16:24:48< iceiceice> it might be better to write a blit routine that takes a non-premultiplied alpha surface
20161015 16:25:10< iceiceice> b/c "unmultiplying the alpha" seems a bit squirrely
20161015 16:25:42< iceiceice> idk it will probably introduce the kind of minor artifacts that would drive you and shadowm insane
20161015 16:26:22< JyrkiVesterinen> I think Aginor is against that idea. He wants us to only use SDL's blit routines in order to make it easier to switch to hardware rendering in the future.
20161015 16:26:52< iceiceice> yah but unmultiplying the alpha is like...
20161015 16:26:58< iceiceice> i think it's probably numerically unstable?
20161015 16:27:05< iceiceice> the way cairo is working is like,
20161015 16:27:18< iceiceice> for each piece of text, it creates a corresponding bitmap
20161015 16:27:24< iceiceice> which is mostly the same hue and such
20161015 16:27:42< iceiceice> but the alpha channel essentially encodes the shapes of the letters etc.
20161015 16:27:47< iceiceice> when you premultiply the alpha,
20161015 16:28:01< iceiceice> the pixels at the very edge of the letter are going to have alpha e.g. 5%, or 1%,
20161015 16:28:17< iceiceice> when the alpha is very small, tkaing the inverse is not numerically stable
20161015 16:28:43< iceiceice> and there's going to be like, variations in the hue i think
20161015 16:28:48< iceiceice> on the edges of the letters
20161015 16:28:57< iceiceice> becaues you'll get like truncation (within cairo)
20161015 16:29:09< iceiceice> and then you try to undo the division with "unpremultiplying the alpha"
20161015 16:29:39< iceiceice> and you'll already have lost many significant bits
20161015 16:30:08< JyrkiVesterinen> Right. The numbers get too small, and they're stored as integers. Custom blit routine is indeed more likely to work.
20161015 16:30:28< iceiceice> it might be that it can be limited to just ttext
20161015 16:30:58< iceiceice> or it could be like a method of ttext, instead of producing a surface representing the rendered text, it takes another surface and blits the text onto that
20161015 16:32:07< iceiceice> idk
20161015 16:32:16< iceiceice> i guess we can try it a few ways
20161015 16:41:00< iceiceice> JyrkiVesterinen, vultraz: i guess that's actually exactly what mordante did
20161015 16:41:13< iceiceice> blit_surface ignores the src_alpha value...
20161015 16:41:23< iceiceice> hmm but then why is he also unpremultiplying the alpha
20161015 16:42:52-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161015 17:00:54-!- Porusaka is now known as Polsaker
20161015 17:07:00-!- louis94 [~~louis94@91.178.242.139] has quit [Ping timeout: 250 seconds]
20161015 17:08:49-!- irker539 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161015 17:15:25< iceiceice> JyrkiVesterinen, i guess the issue i raised might not ultimately matter
20161015 17:15:41< iceiceice> because the blend routine is ultimately going to multiply the other channels by alpha
20161015 17:16:05< iceiceice> as long as that perfectly undoes whatever "unmultiplying" you do then there should be no loss of precision i guess
20161015 17:16:27< iceiceice> idk exactl how sdl blit functions are implemented tho
20161015 17:23:01-!- un214 [~un214@104.220.56.173] has joined #wesnoth-dev
20161015 17:24:54< iceiceice> vultraz, i am done with that PR i think
20161015 17:24:57< iceiceice> bbl
20161015 17:25:09-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Quit: Ex-Chat]
20161015 17:30:07-!- Polsaker [~Polsaker@wikimedia/botters.Polsaker] has quit [Changing host]
20161015 17:30:07-!- Polsaker [~Polsaker@donger/wielder/Polsaker] has joined #wesnoth-dev
20161015 17:49:27-!- Kwandulin [~Miranda@p200300760F2C71120429CF15DF73E505.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161015 17:52:19-!- travis-ci [~travis-ci@ec2-54-160-188-238.compute-1.amazonaws.com] has joined #wesnoth-dev
20161015 17:52:20< travis-ci> cbeck88/wesnoth#189 (font_refactor - b280639 : Chris Beck): The build has errored.
20161015 17:52:20< travis-ci> Build details : https://travis-ci.org/cbeck88/wesnoth/builds/167915003
20161015 17:52:20-!- travis-ci [~travis-ci@ec2-54-160-188-238.compute-1.amazonaws.com] has left #wesnoth-dev []
20161015 17:59:22-!- un214 [~un214@104.220.56.173] has quit [Remote host closed the connection]
20161015 18:35:17-!- Kwandulin [~Miranda@p200300760F2C7112DC984424A6E6FBD6.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161015 18:46:33-!- gfgtdf [~chatzilla@x4e32b220.dyn.telefonica.de] has quit [Remote host closed the connection]
20161015 19:15:37-!- JyrkiVesterinen [~JyrkiVest@87-92-16-107.bb.dnainternet.fi] has quit [Quit: .]
20161015 19:23:25-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161015 19:39:00-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161015 19:50:39-!- mjs-de [~mjs-de@x4db6da21.dyn.telefonica.de] has joined #wesnoth-dev
20161015 20:05:44-!- gfgtdf [~chatzilla@x4e32b220.dyn.telefonica.de] has joined #wesnoth-dev
20161015 20:09:50-!- gfgtdf [~chatzilla@x4e32b220.dyn.telefonica.de] has quit [Client Quit]
20161015 20:15:00-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161015 20:37:08< mattsc> So I’ve come up against an interesting philosophical question: does a coward run away from a petrified enemy?  ;)
20161015 20:38:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161015 20:40:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161015 20:42:37< zookeeper> mattsc, uh... hard to say. i guess whichever makes it possible to have both behaviors (via [filter_second])?
20161015 20:42:57< tad_carlucci> Depends on whether he's intelligent. An intelligent coward would notice the enemy is petrified. A cautious intelligent coward would verify the petrifucation.
20161015 20:45:18< mattsc> zookeeper: ah, man, that reply makes way too much sense  :P
20161015 20:45:38< mattsc> tad_carlucci: yeah, something like that
20161015 20:55:08-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161015 20:56:51< tad_carlucci> mattsc, Of the top of your head, are we using floating-point numbers in any AI and, if so, are any of them treated as integers at some point?
20161015 20:58:06< mattsc> tad_carlucci: you mean the custom Lua AIs I presume?
20161015 20:58:30< tad_carlucci> mattsc, That or C++ which reaches into Lua for those numbers.
20161015 20:59:15< tad_carlucci> The way Lua works, we're probably quite safe if what happens in Lua, stays in Lua.
20161015 20:59:35< mattsc> Yes, most of them use floats for their rating system, but they are not compared to integers for anything.  At least not for anythign where the float precision matters.
20161015 21:00:58< mattsc> As in, I might compare a rating to zero, but if that is done, it is either exactly zero (set to zero at the beginning), or way larger than zero (say, 10 or 100 above)
20161015 21:01:15< tad_carlucci> OK. My concern is I can't test all those AI. If it's all inside Lua, the problems are minor like printing "1" instead of "1.0" or having to implicity convert 10 to 10.0 to compare to a float.
20161015 21:02:04< mattsc> Something like that won’t matter for the AI code that I know about.
20161015 21:02:05< tad_carlucci> The issue is if C++ wants that float and asks for it as an integer, the API will crash unless the float has no fractiononal part, and can be represented as an integer.
20161015 21:02:48< tad_carlucci> I checked and didn't see any of that, but most of it has to do with AI, so you're more likely to know.
20161015 21:03:20< mattsc> I don’t think we have anything like that in the code.
20161015 21:03:44< mattsc> *in the Lua AI code, I mean
20161015 21:04:38< tad_carlucci> Well, in Lua it's all "numbers" and only becomes apparent if you parse or print them. It's the API which can bite hard since it will crash the game if it happens.
20161015 21:05:16< mattsc> Right.  I am thinking about where that might happen.
20161015 21:05:37< mattsc> Weapon numbers and hex coordinates, I guess.  But those are never calculated.
20161015 21:06:26< mattsc> The only thing I could think of is the switch between cartesian and hexagonal coordinates, but that’s only done from hex coordinates to cartesian, IIRC.
20161015 21:06:55< mattsc> All the evaluation ratings, which really need to be floats, are Lua internal only.
20161015 21:07:11< mattsc> So unless I am forgetting something, I think we’re good.
20161015 21:08:21< tad_carlucci> That was my impression, too.  I do, as well. I scanned and glanced at all the C++ fetching integers from Lua and it looks good; the numbers should be integer or integer-like.
20161015 21:08:51< tad_carlucci> So, since UMC can't get at the C++, we're probably OK, there, too.
20161015 21:16:12-!- iwaim [~iwaim@124.146.179.10] has quit [Ping timeout: 260 seconds]
20161015 21:16:22-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161015 21:18:27-!- stikonas__ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161015 21:19:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20161015 21:21:37-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20161015 21:24:28-!- stikonas__ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161015 21:25:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161015 21:26:13-!- iwaim [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20161015 21:26:59-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161015 21:27:18-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161015 21:30:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 250 seconds]
20161015 21:59:32-!- louis94 [~~louis94@91.178.242.139] has joined #wesnoth-dev
20161015 22:01:06-!- stikonas_ is now known as stikonas
20161015 22:04:54-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.]
20161015 22:10:53-!- Kwandulin [~Miranda@p200300760F2C7112DC984424A6E6FBD6.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161015 22:13:06-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161015 22:20:11-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 258 seconds]
20161015 22:30:58-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Switching to Unix to get some real work done.]
20161015 22:55:39-!- mjs-de [~mjs-de@x4db6da21.dyn.telefonica.de] has quit [Remote host closed the connection]
20161015 22:57:53-!- gfgtdf [~chatzilla@x4e32b220.dyn.telefonica.de] has joined #wesnoth-dev
20161015 23:10:55-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161015 23:22:11-!- louis94 [~~louis94@91.178.242.139] has quit [Quit: Konversation terminated!]
20161015 23:22:26-!- louis94 [~~louis94@91.178.242.139] has joined #wesnoth-dev
20161015 23:36:06-!- louis94 [~~louis94@91.178.242.139] has quit [Ping timeout: 252 seconds]
20161015 23:37:11-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection]
20161015 23:53:59-!- Bonobo [~Bonobo@2001:44b8:254:3200:b8da:6dd0:abc0:d027] has joined #wesnoth-dev
--- Log closed Sun Oct 16 00:00:41 2016