--- Log opened Thu Dec 01 00:00:35 2016
20161201 00:01:24-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161201 00:10:46-!- irker095 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161201 00:23:06-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161201 00:46:23-!- atarocch [~atarocch@host-78-65-187-41.homerun.telia.com] has quit [Remote host closed the connection]
20161201 00:50:02-!- Appleman1234 [~Appleman1@KD106161205216.au-net.ne.jp] has quit [Ping timeout: 256 seconds]
20161201 00:51:08-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161201 00:54:29-!- Appleman1234 [~Appleman1@KD106161214141.au-net.ne.jp] has joined #wesnoth-dev
20161201 00:56:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 00:58:12-!- Shiki [~Shiki@141.39.226.226] has quit [Quit: Verlassend]
20161201 01:10:59< vultraz> dammit irker
20161201 01:11:06-!- 18WAAV5NE [~travis-ci@ec2-54-90-108-235.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 01:11:06< 18WAAV5NE> wesnoth/wesnoth#12237 (master - 3e0797d : Charles Dang): The build was broken.
20161201 01:11:06< 18WAAV5NE> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180210362
20161201 01:11:06-!- 18WAAV5NE [~travis-ci@ec2-54-90-108-235.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 01:11:07-!- irker507 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161201 01:11:07< irker507> wesnoth: Charles Dang wesnoth:master f37732bec700 / src/game_config.cpp: Removed debug output (accidentally included in 3e0797d3a6c2) https://github.com/wesnoth/wesnoth/commit/f37732bec700848cf5302853d720d3846d6455b0
20161201 01:11:58< vultraz> celticminstrel: are anon namespaces implicitly static?
20161201 01:12:31< vultraz> also.. uh.. src/sdl/color.hpp:22:17: fatal error: SDL.h: No such file or directory #include <SDL.h>
20161201 01:12:33< vultraz> what
20161201 01:12:42< vultraz> did someone change travis
20161201 01:13:25< celticminstrel> Variables in anonymous namespaces have file-static storage.
20161201 01:13:51< celticminstrel> Which is the same as declaring a global variable static.
20161201 01:19:20 * vultraz makes note to implement proper checkboxes in drop down menus
20161201 01:19:54< celticminstrel> What for?
20161201 01:20:32< vultraz> a mods dropdown in Campaigns
20161201 01:20:39< vultraz> and the music menu in the editor
20161201 01:20:47< vultraz> right now it's just an image
20161201 01:20:51< vultraz> not an actual checkbox
20161201 01:21:09< celticminstrel> The only downside to that is that the scrollbar resets when you click one.
20161201 01:21:17< celticminstrel> ...admittedly that's a fairly large downside.
20161201 01:21:37< vultraz> indeed :P
20161201 01:34:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161201 01:36:03< vultraz> is this a valid function argument?
20161201 01:36:05< vultraz>  const std::string game_config::sounds* member
20161201 01:36:20< DeFender1031> no
20161201 01:36:38< vultraz> hm
20161201 01:36:39< DeFender1031> is the type std::string or game_config::sounds?
20161201 01:36:54< vultraz> string member of game_config::sounds
20161201 01:37:02< DeFender1031> huh?
20161201 01:37:19< DeFender1031> if something is a function argument, it's passed from elsewhere
20161201 01:38:32< vultraz> I thought one could have a pointer-to-member... though I suppose that might only apply to objects not namespaces
20161201 01:38:34< vultraz> hmm
20161201 01:42:59-!- gimemor [~gimemor@host-95-152-34-56.dsl.sura.ru] has joined #wesnoth-dev
20161201 01:43:18< gimemor> #join wesnoth
20161201 01:45:40< vultraz> hmmm
20161201 01:46:11< vultraz> yeah, there rather is the problem of not having classes her
20161201 01:46:12< vultraz> e
20161201 01:47:26< celticminstrel> vultraz: Pointer-to-member has the sequence ::*
20161201 01:47:42< celticminstrel> And yes it only applies to classes, not namespaces.
20161201 01:48:28< vultraz> so I guess there's no way to say, given a string, assign the namespace member of the same name the value config[str].str()?
20161201 01:59:52-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 01:59:53< travis-ci> wesnoth/wesnoth#12238 (master - fc15712 : Charles Dang): The build was broken.
20161201 01:59:53< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180212681
20161201 01:59:53-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 02:04:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 02:08:19-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161201 02:08:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161201 02:10:51-!- gfgtdf_ [~chatzilla@x4e36900c.dyn.telefonica.de] has joined #wesnoth-dev
20161201 02:10:59< celticminstrel> vultraz: Sorry, what are you asking?
20161201 02:11:50< vultraz> say you have a string with value "str"
20161201 02:12:05< vultraz> and in namespace foo, there's a string variable named "str"
20161201 02:12:30< celticminstrel> Oh, yeah, that's impossible.
20161201 02:12:36< vultraz> ok
20161201 02:12:48-!- gfgtdf [~chatzilla@x4e369fde.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
20161201 02:12:53< celticminstrel> There's no way to transform a string to a symbol.
20161201 02:13:00-!- gfgtdf_ is now known as gfgtdf
20161201 02:13:17< vultraz> so that's what it's called
20161201 02:13:19< celticminstrel> (At least, not within the C++ standard. Obviously there are ways.)
20161201 02:13:32< celticminstrel> (Otherwise it'd be impossible to load DLLs.)
20161201 02:14:20< vultraz> i suppose i could use a macro
20161201 02:14:45< celticminstrel> What are you doing?
20161201 02:15:21< vultraz> cleaning up game_config
20161201 02:15:59< celticminstrel> That's too vague.
20161201 02:16:18< vultraz> since basically every namespace variable's name matches the config key, I was wondering if there was a way to simply dynamically say "iterate the config, take each key, and assign the variable in this namespace with the same name to the value"
20161201 02:17:12< celticminstrel> There isn't any way to do that.
20161201 02:17:13< vultraz> ie, for game_config::turn_bell, the value is stored in cfg["turn_bell"]
20161201 02:17:49< celticminstrel> The best you'd be able to manage is probably something involving Boost.Preprocessor.
20161201 02:18:40< vultraz> if game_config were a class, could pointer-to-member be used?
20161201 02:19:39< celticminstrel> I'm not sure if pointer-to-member works for static members, but if it was a singleton, I guess you could have a map of string->pointers and interate over that.
20161201 02:19:57< celticminstrel> That still means every name appears at least three times though.
20161201 02:20:16< celticminstrel> (Once as a map key; once as a map value; once for the actual declaration.)
20161201 02:20:44< celticminstrel> Again, you'd probably need something like Boost.Preprocessor to fully abstract away any duplication.
20161201 02:21:18< celticminstrel> (Boost.Preprocessor has various ways of looping through stuff at the preprocessor stage.)
20161201 02:22:11< vultraz> I see
20161201 02:22:49< celticminstrel> IIRC Boost.Preprocessor is already used in Wesnoth (for MAKE_ENUM).
20161201 02:24:05< vultraz> it is
20161201 02:26:05< vultraz> hm. odd. brace initialization doesn't work with ctors with only optional arguments?
20161201 02:27:01< celticminstrel> I know no reason why it wouldn't?
20161201 02:49:42< irker507> wesnoth: Charles Dang wesnoth:master 6054ad3d6d4a / src/game_config.cpp: Game Config: totally reformat file https://github.com/wesnoth/wesnoth/commit/6054ad3d6d4a906950dc015311eba37d2be2018d
20161201 02:53:06< vultraz> good luck git blaming anything after that :P
20161201 02:59:30< celticminstrel> Will that fix the broken build? (Or is there something else still building that will?)
20161201 03:01:28< vultraz> I have no idea why the build is broken
20161201 03:01:40< celticminstrel> ...did you take a look?
20161201 03:01:41< vultraz> it says <SDL.h> is not a valid include
20161201 03:01:45< celticminstrel> Ah.
20161201 03:01:54< celticminstrel> So that was from Travis.
20161201 03:07:56< vultraz> .... now every single color is green ._.
20161201 03:08:06< vultraz> (in red_to_green)
20161201 03:09:40< vultraz> ...odd
20161201 03:09:51< vultraz> that seemed to be a result of using util::clamp :/
20161201 03:09:52< vultraz> but why
20161201 03:11:58< vultraz> ohh
20161201 03:12:01< vultraz> I screwed up the syntax
20161201 03:12:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161201 03:13:20< irker507> wesnoth: Charles Dang wesnoth:master dcbf25e189dd / src/game_config.cpp: Small fixup to 6054ad3d6d4a https://github.com/wesnoth/wesnoth/commit/dcbf25e189ddc25792c6c4bcbcff4d8f6c20cc48
20161201 03:19:14< vultraz> really i wish i could figure out why these colors are wrong
20161201 03:19:26< vultraz> (the terrain defense ones)
20161201 03:33:54< vultraz> next big thing is converting color_range to use color_t
20161201 03:34:16< Aginor> rgba vs argb ?
20161201 03:35:32< vultraz> Aginor: I don't see how... but *possibly*... Previously the color was a uint32_t and fetched with from_argb_bytes...  but now we no longer have the uint32_t variable and I've confirmed that hex string is converted to color_t correctly with from_hex_string
20161201 03:36:30< Aginor> I'd suggest dumping the raw values instead of relying on yet another conversion function
20161201 03:37:15< vultraz> what?
20161201 03:37:28< Aginor> you could probably write a few unit tests as well to help you fix the code
20161201 03:37:52< Aginor> disregard my previous statement, I failed at reading :)
20161201 03:37:54< vultraz> previously we had hex string -> vector of uint32_t -> from_argb_bytes
20161201 03:38:09< vultraz> now we have hex_string -> from_hex_string to make a vector of color_t
20161201 03:38:47< vultraz> I have confirmed the color is correct when converted to color_t
20161201 03:38:51< vultraz> nothing else changed
20161201 03:38:57< vultraz> but somehow, the color comes out wrong :|
20161201 03:45:28-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 245 seconds]
20161201 03:46:18< Aginor> a unit test or two might help you to narrow down on the somehow
20161201 03:46:31< Aginor> it sounds like one of those situations where I'd write on
20161201 03:59:10< celticminstrel> Yeah, this would be a great place for some unit tests.
20161201 04:00:55-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 04:00:56< travis-ci> wesnoth/wesnoth#12240 (master - 3d7f143 : Charles Dang): The build was broken.
20161201 04:00:57< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180214192
20161201 04:00:57-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 04:01:38< vultraz> ...huh
20161201 04:01:42< vultraz> problem, I have discovered
20161201 04:04:46< vultraz> fix, I have found :D
20161201 04:06:50-!- JyrkiVesterinen [~JyrkiVest@87-100-135-132.bb.dnainternet.fi] has joined #wesnoth-dev
20161201 04:12:17< irker507> wesnoth: Charles Dang wesnoth:master 80c372b4a054 / src/game_config.cpp: Game Config: fixed red_to_green and blue_to_white returning incorrect values https://github.com/wesnoth/wesnoth/commit/80c372b4a054e2150f57277dc3e8d2af982a59b8
20161201 04:12:18< vultraz> celticminstrel: ^
20161201 04:13:08< vultraz> only discovered this by checking the vector size
20161201 04:21:34-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161201 04:25:01< vultraz> oh dear 
20161201 04:25:02< vultraz> uint16_t
20161201 04:25:11< celticminstrel> ?
20161201 04:25:26< vultraz> I guess these can be color_t too
20161201 04:25:28< celticminstrel> BTW I'd say that lambda probably shouldn't be.
20161201 04:25:45< celticminstrel> uint16_t is... max 0xffff.
20161201 04:25:56< celticminstrel> Is that seriously used for colours somewhere?
20161201 04:25:58< vultraz> i'm working on color_range..
20161201 04:26:12< vultraz> used to keep each of its 4 components as uint32_t
20161201 04:26:17< vultraz> I'm making that color_t
20161201 04:26:19< celticminstrel> (The lambda I'm talking about is parse_config_color_list.)
20161201 04:26:28< celticminstrel> What was that about uint16_t?
20161201 04:26:37< vultraz> but recolor_range uses uint16_t internally
20161201 04:26:42< vultraz> uint16_t new_red  = (new_range.mid() & 0x00FF0000)>>16;
20161201 04:26:56< celticminstrel> Where is this?
20161201 04:27:05< vultraz> color_range.cpp
20161201 04:27:14< celticminstrel> Found it.
20161201 04:27:24< vultraz> trying to figure out how to use color_t for this
20161201 04:27:30< celticminstrel> I guess it's using uint16_t as components.
20161201 04:27:48< irker507> wesnoth: Gregory A Lundberg wesnoth:master 6202a10bcc09 / .appveyor.vs2013.yml .appveyor.vs2015.yml: Fix YML for AppVeyor IRC https://github.com/wesnoth/wesnoth/commit/6202a10bcc096b507c123314d947abadb4828023
20161201 04:27:48< vultraz> I don't really understand this function at all
20161201 04:27:50< irker507> wesnoth: Jyrki Vesterinen wesnoth:master 3dc2fa960d0f / .appveyor.vs2013.yml .appveyor.vs2015.yml: Merge pull request #888 from GregoryLundberg/GL_appveyor_irc https://github.com/wesnoth/wesnoth/commit/3dc2fa960d0f997336a9d6c5f189a4f7a8760126
20161201 04:29:18< vultraz> what is it even doing
20161201 04:30:05< celticminstrel> Guessing one of the reasons for uint16_t is to avoid overflows in intermediate calculations.
20161201 04:30:32< celticminstrel> Safest route is probably to replace only the uint32_t's with color_t.
20161201 04:30:44< vultraz> ok..
20161201 04:31:25< vultraz> so.. say
20161201 04:31:31< vultraz> new_range.mid() & 0x00FF0000
20161201 04:31:40< vultraz> if color_range stores 4 color_t members
20161201 04:31:46< vultraz> that would be color_t
20161201 04:31:54< celticminstrel> Say that again?
20161201 04:31:57< vultraz> so do I just do new_range.mid().r & 0x00FF0000 >> 16?
20161201 04:32:16< vultraz> celticminstrel: color_range stores 4 uint32_t's
20161201 04:32:42-!- SigurdFD [~SigurdFD@dynamic-acs-72-23-110-196.zoominternet.net] has joined #wesnoth-dev
20161201 04:32:46< vultraz> how do I handle this if I change it to 4 color_t's
20161201 04:33:56< vultraz> ie, do I just pull out the components, then bitshift?
20161201 04:34:01< vultraz> or components, no shift?
20161201 04:34:24< celticminstrel> eg "uint16_t new_red = new_range.mid().r;"
20161201 04:34:34< celticminstrel> That's exactly what line 33 is doing, right?
20161201 04:34:40< celticminstrel> Retrieving the red component.
20161201 04:34:53< vultraz> as far as I can tell, yes
20161201 04:34:54< celticminstrel> Why would you need to bitshift?
20161201 04:34:59< vultraz> dunno 
20161201 04:35:01< vultraz> just checking
20161201 04:35:09< vultraz> if I can just fetch the compoents this is even easier
20161201 04:35:13< vultraz> components 
20161201 04:35:55< celticminstrel> ?
20161201 04:36:12< vultraz> but wait
20161201 04:36:20< vultraz> then I can change it to uint8_t
20161201 04:36:27< celticminstrel> ?
20161201 04:36:28< vultraz> right?
20161201 04:36:37< vultraz> uint16_t new_red   = new_range.mid().r;
20161201 04:36:39< vultraz> can be made
20161201 04:36:42< vultraz> uint8_t new_red   = new_range.mid().r;
20161201 04:36:44< celticminstrel> No.
20161201 04:36:47< vultraz> no?
20161201 04:36:52< celticminstrel> Look at line 80 for example.
20161201 04:37:05< celticminstrel> It's clearly assuming it could exceed 255 at some point.
20161201 04:37:20< vultraz> so it should be uint16_t?
20161201 04:37:28< vultraz> should remain*
20161201 04:37:53< celticminstrel> If you make it uint8_t you'll need to take measures to avoid overflow in other ways, so I'd recommend leaving it.
20161201 04:38:25< vultraz> hmmm
20161201 04:38:27< vultraz> color_t temp_rgb   = old_rgb.empty() ? 0 : old_rgb[0];
20161201 04:38:46< vultraz> i guess .null()
20161201 04:38:51< vultraz> except null considers alpha..
20161201 04:39:12< celticminstrel> old_rgb is a vector.
20161201 04:39:22< vultraz> oh right
20161201 04:39:24< vultraz> duh
20161201 04:39:30< vultraz> forgot..
20161201 04:39:45-!- gfgtdf [~chatzilla@x4e36900c.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 50.0.1/20161123182536]]
20161201 04:42:41< vultraz> hmmm
20161201 04:42:43< vultraz> new_r=uint32_t( old_rat * new_red   + (1 - old_rat) * min_red);
20161201 04:42:54< vultraz> old...rat.
20161201 04:43:41< celticminstrel> Not entirely sure what that means TBH. My first guess would be "rate" or "rating" but not sure if that makes sense here.
20161201 04:43:50< vultraz> ok, I guess these variable should stay uint32_t
20161201 04:43:55< celticminstrel> Oh, maybe "ratio".
20161201 04:44:06< vultraz> variables
20161201 04:44:07< celticminstrel> Should they?
20161201 04:44:18< celticminstrel> Oh, new_r etc?
20161201 04:44:24< vultraz> yes
20161201 04:44:27< celticminstrel> Since they're components, sure.
20161201 04:45:19< celticminstrel> "if(255 - reference_avg)" looks super-suspicious BTW
20161201 04:45:40< vultraz> oh?
20161201 04:46:01< celticminstrel> Yeah...
20161201 04:46:17< vultraz> what should it be?
20161201 04:46:29< celticminstrel> It's probably not a bug, since I'd've expected such a thing to be discovered by now...
20161201 04:46:50< celticminstrel> Well, it enters that if() when 255-reference_avg yields a nonzero value.
20161201 04:46:57< celticminstrel> So, 255 != reference_avg, effectively.
20161201 04:47:41< vultraz> hm, yes
20161201 04:47:44< vultraz> makes sense
20161201 04:47:46< vultraz> I'll make it that
20161201 04:47:47-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 04:50:02< vultraz> this look good? http://pastebin.com/yNWesJ69
20161201 04:52:19< celticminstrel> You could eliminate old_r, old_g, old_b altogether by combining lines 20-24 in the same way you did it at line 27.
20161201 04:52:49< vultraz> oh yeah
20161201 04:52:56< celticminstrel> Pretty sure now that rat means ratio.
20161201 04:53:43< celticminstrel> static_cast at line 67 probably isn't needed, but I guess it never hurts.
20161201 04:53:54< celticminstrel> (It is needed on line 62 though.)
20161201 04:54:07 * celticminstrel referring to static_cast<float>
20161201 04:54:29< celticminstrel> Only bad thing I see is the bitshifts right at the end.
20161201 04:55:10< vultraz> is it safe to replace if(new_r > 255) new_r = 255;, etc, with std::min?
20161201 04:55:13< celticminstrel> ...what's with all the (*temp_rgb) in the original?
20161201 04:55:16< celticminstrel> Sure.
20161201 04:55:31< JyrkiVesterinen> The use of color_t default constructor looks a bit bad to me.
20161201 04:55:47< celticminstrel> Oh, temp_rgb2 is different from temp_rgb.
20161201 04:55:54< JyrkiVesterinen> Programmers reading the code may assume that the default constructor doesn't initialize the color to any value.
20161201 04:56:08< celticminstrel> It initializes it to opaque white.
20161201 04:56:10< vultraz> I've changed the final line to map_rgb[old_c] = {new_r << 16, new_g << 8, new_b};
20161201 04:56:18< celticminstrel> Which I'm pretty sure is the same effect as the previous code.
20161201 04:56:39< celticminstrel> vultraz: You didn't shift when retrieving the components, so why are you shifting when storing them?
20161201 04:56:49< vultraz> "?
20161201 04:57:00< vultraz> these are new components
20161201 04:57:07< vultraz> uint32_t
20161201 04:57:15< celticminstrel> How is that relevant?
20161201 04:57:24< vultraz> do I not need to shift them?
20161201 04:57:28< celticminstrel> Just FYI, by shifting them you effectively make them 0.
20161201 04:57:39< celticminstrel> I think.
20161201 04:57:45< vultraz> so, just map_rgb[old_c] = {new_r, new_g, new_b}; ?
20161201 04:57:47< celticminstrel> Maybe it'd wrap around to something.
20161201 04:57:49< celticminstrel> Yes.
20161201 04:57:56< vultraz> ok
20161201 04:58:05< celticminstrel> I see, so old_c is your replacement for temp_rgb2.
20161201 04:59:09< vultraz> yes
20161201 04:59:38< vultraz> now to deal with palette
20161201 05:02:59-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161201 05:03:54-!- SigurdFD [~SigurdFD@dynamic-acs-72-23-110-196.zoominternet.net] has quit []
20161201 05:04:12< tad_carlucci> In file included from src/game_config.hpp:21:
20161201 05:04:13< tad_carlucci> src/sdl/color.hpp:22:10: fatal error: 'SDL.h' file not found
20161201 05:04:26< tad_carlucci> ???
20161201 05:04:35< celticminstrel> That's what we're confused about too.
20161201 05:06:03< JyrkiVesterinen> I'm getting a linking error when trying to build wesnothd.
20161201 05:06:35< JyrkiVesterinen> The game_config class (in wesnothlib) depends on color_t (in wesnoth).
20161201 05:07:04< tad_carlucci> Well, didn't someone just basically rewrite the entire file? 
20161201 05:07:05< JyrkiVesterinen> I suspect that the "SDL.h not found" problem is caused by that, too.
20161201 05:07:47< celticminstrel> Hmm.
20161201 05:07:51< JyrkiVesterinen> It wouldn't be surprising that SDL headers are not added to the include path when building wesnothlib.
20161201 05:08:33< vultraz> ughh
20161201 05:08:36< vultraz> this function
20161201 05:08:39< celticminstrel> I'd say color_t should be in wesnothlib.
20161201 05:08:40< celticminstrel> BUT
20161201 05:08:45< celticminstrel> SDL shouldn't be.
20161201 05:08:50< vultraz> at loss, I am, what to do...
20161201 05:08:50< celticminstrel> So that's a bit of a conundrum.
20161201 05:09:07< tad_carlucci> s%<SDL%<SDL2/SDL%
20161201 05:09:14< celticminstrel> ???
20161201 05:09:19< vultraz> guess I need from_rgba_bytes
20161201 05:09:30< tad_carlucci> SDL.h is SDL2/SDL.h on my system
20161201 05:09:57< tad_carlucci> Got the compile running.
20161201 05:10:48< vultraz> res.push_back(cmap[255]);
20161201 05:10:59< vultraz> how am I possibly supposed to do this in the context of color_t..
20161201 05:11:32< vultraz> oh, don't tell me I need to implement operator< now too
20161201 05:11:36< celticminstrel> If you want responses you'll need to give more information.
20161201 05:11:59< vultraz> http://pastebin.com/9XtqSBZ7
20161201 05:13:03< vultraz> I'm not even sure what it's doing
20161201 05:13:19< vultraz> giving every single color in a range?
20161201 05:13:20< celticminstrel> Okay so
20161201 05:13:36< celticminstrel> Why on earth are you using from_rgba_bytes
20161201 05:13:40< celticminstrel> Instead of the basic constructor
20161201 05:13:53< tad_carlucci> clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)
20161201 05:14:09< tad_carlucci> src/game_config.cpp:357: undefined reference to `color_t::from_hex_string
20161201 05:14:37< vultraz> there is no basic ctor for uint32_t :/
20161201 05:16:15< celticminstrel> But that code is building the uint32_t up from the components!
20161201 05:16:31< celticminstrel> color_t(0,0,i) and color_t(j,j,255)
20161201 05:16:45< vultraz> oh...
20161201 05:16:47< celticminstrel> Could be a good place for emplace_back
20161201 05:18:59-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 05:19:00< travis-ci> wesnoth/wesnoth#12242 (master - f37732b : Charles Dang): The build is still failing.
20161201 05:19:00< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180271406
20161201 05:19:00-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 05:19:03< vultraz> not exactly sure where you get 0 for r and g in the first one
20161201 05:19:06< vultraz> instance*
20161201 05:19:19< celticminstrel> Because they're omitted.
20161201 05:20:20< irker507> wesnoth: Celtic Minstrel wesnoth:maybe_fix_travis dfedf34f1f96 / src/ (color.cpp color.hpp sdl/color.cpp sdl/color.hpp sdl/utils.cpp): Attempt to fix Travis https://github.com/wesnoth/wesnoth/commit/dfedf34f1f96fc71f5122ac1a5dc0f4ed3170bc0
20161201 05:20:33< celticminstrel> ...oh wait. Missed a thing in that.
20161201 05:21:11< vultraz> ok, so just
20161201 05:21:13< vultraz> 		temp.emplace_back(0,0,i);
20161201 05:21:14< vultraz> 		temp.emplace_bacl(j,j,255);
20161201 05:21:16< vultraz> ?
20161201 05:21:18< vultraz> k*
20161201 05:21:21< celticminstrel> Yeah.
20161201 05:21:50< vultraz> why did you move that to utils.cpp
20161201 05:21:53< vultraz> not color.cpp :/
20161201 05:22:26< celticminstrel> Putting it in color.cpp would solve nothing.
20161201 05:22:31< vultraz> also, still not sure what to do with res.push_back(cmap[255]);
20161201 05:22:44< vultraz> I assume it means 255,0,0, and I need operator<..
20161201 05:24:13< vultraz> hm?
20161201 05:24:18< vultraz> ..*
20161201 05:24:35< vultraz> well i definitely need operator< since it's map lookup
20161201 05:25:14< vultraz> ah, I already need operator<
20161201 05:25:33< vultraz> since color_range::operator< assumes operator< for its components
20161201 05:26:50< vultraz> ok...
20161201 05:27:08< irker507> wesnoth: Celtic Minstrel wesnoth:maybe_fix_travis 05127581cba0 / src/ (39 files in 14 dirs): Attempt to fix Travis, part II https://github.com/wesnoth/wesnoth/commit/05127581cba0754a70ebee8de8ef92c7083e160c
20161201 05:27:09< vultraz> so should that become res.push_back[{255,0,0}]?
20161201 05:27:17< celticminstrel> So what's the issue with operator< now.
20161201 05:27:56< vultraz> the line res.push_back(cmap[255]); is a map lookup
20161201 05:28:03< celticminstrel> Oh. It's using the colour as a map key, huh.
20161201 05:28:08< celticminstrel> I guess you need operator<.
20161201 05:28:12< celticminstrel> Make it a lexicographical compare.
20161201 05:28:15< vultraz> plus color_range::operator< uses operator< for its components
20161201 05:28:18< vultraz> eh?
20161201 05:28:39< celticminstrel> Make color_t::operator< a lexicographical compare.
20161201 05:28:49< celticminstrel> (Don't forget to declare the function const as well.)
20161201 05:29:05< vultraz> I was just going to do return r < c.r && g < c.g && b < c.b && a < c.a;
20161201 05:29:08< vultraz> I assume that's wrong
20161201 05:29:13< celticminstrel> That's quite wrong.
20161201 05:29:20< celticminstrel> It's not a total order.
20161201 05:29:43< celticminstrel> You need lexicographical comparison. I don't think there's any other total order for vectors.
20161201 05:29:45< tad_carlucci> I fail to see how < <= > or >= apply to colors. == and != are the only things which make sense to me
20161201 05:29:57< vultraz> to_rgb_string() < c.to_rgb_string()?
20161201 05:29:58< celticminstrel> tad_carlucci: Well, I definitely agree.
20161201 05:30:07< celticminstrel> tad_carlucci: However, std::map requires a comparison to work.
20161201 05:30:08< vultraz> er, rgba_string*
20161201 05:30:20< celticminstrel> As an alternative you could use unordered_map instead.
20161201 05:30:33< celticminstrel> vultraz: Well, that would be a lexicographical compare, certainly; it's not how I'd do it though.
20161201 05:31:07< celticminstrel> Using unordered_map still means you need to implement hash, but you could just make that wrap to_rgba_bytes.
20161201 05:31:28< tad_carlucci> I'd suggest a map with a custom comparator rather than making up a general purpose comparitor. Keep the mess as local as possible.
20161201 05:31:37< vultraz> whaa?
20161201 05:31:39< celticminstrel> tad_carlucci: That's a possibility too.
20161201 05:31:43< vultraz> I've never used unordered_map
20161201 05:31:53< vultraz> what is this about a wrapping operator?
20161201 05:31:57< celticminstrel> vultraz: It's exactly the same as map in almost every way.
20161201 05:32:05< celticminstrel> The only difference is that you don't need operator<
20161201 05:32:11< celticminstrel> Instead you need hash and operator==
20161201 05:32:27< celticminstrel> (And there's different performance expectations too.)
20161201 05:32:31< vultraz> color_range::operator< uses < on its components
20161201 05:32:38< celticminstrel> (But I'm referring to the API only.)
20161201 05:32:39< vultraz> 		if(mid_ != b.mid()) return(mid_ < b.mid());
20161201 05:32:40< vultraz> 		if(max_ != b.max()) return(max_ < b.max());
20161201 05:32:42< vultraz> 		if(min_ != b.min()) return(min_ < b.min());
20161201 05:32:44< vultraz> 		return(rep_ < b.rep());
20161201 05:32:49< celticminstrel> You could make them use something else.
20161201 05:33:14< celticminstrel> Why does color_range have operator<?
20161201 05:33:22< vultraz> don't ask me
20161201 05:33:32< celticminstrel> Well, try commenting it out and see what breaks? :P
20161201 05:34:23< vultraz> a million things are going to break anyway :P
20161201 05:34:29< vultraz> so alright
20161201 05:34:49< vultraz> but I still don't know what exactly that push_back call is for anyway..
20161201 05:34:59< vultraz> push back blue?
20161201 05:35:01< vultraz> red?
20161201 05:35:15< vultraz> (well, the color associated with blue/red?)
20161201 05:35:56< celticminstrel> Well, 255 in 0RGB is blue.
20161201 05:36:59< vultraz> but why is it adding the associated-with-blue color!
20161201 05:37:56< vultraz> and what is this hash op for unordered_maps
20161201 05:38:04< celticminstrel> std::hash
20161201 05:38:30< celticminstrel> To use a custom type as an unordered_map key you need a template specialization of the std::hash clas.
20161201 05:38:32< celticminstrel> ^class
20161201 05:38:42< celticminstrel> You could look in map/location.hpp for an example IIRC
20161201 05:40:53< vultraz> so just return to_rgba_bytes()?
20161201 05:52:51< celticminstrel> That should be sufficient, yeah.
20161201 05:52:54< celticminstrel> I think.
20161201 05:53:24< celticminstrel> I guess maybe it's not great for uniformity...
20161201 05:54:02< celticminstrel> But there'll be no chance of collisions, so maybe that doesn't matter.
20161201 05:54:34< celticminstrel> (Because the range of the hashed value is actually greater than the range of the original value - 64 bits vs 32 bits - or at worst equal.)
20161201 05:55:24< celticminstrel> It's also invertible, but that's only a problem for cryptography.
20161201 05:56:12< celticminstrel> I guess it's technically a "perfect hash function".
20161201 05:56:58 * celticminstrel will stop rambling about pointless things now.
20161201 05:57:24< tad_carlucci> You're talking about using the raw rgba byte values as the hash? That will work. It won't be efficient but it'll work. Things may be a bit slow here or there due to excessive collisions.
20161201 05:57:50< celticminstrel> Huh? How would there be collisions?
20161201 05:58:09< tad_carlucci> [hash] mod [tablesize]
20161201 05:58:42< celticminstrel> Well, std::hash returns size_t, so 64 bits on most machines...
20161201 05:59:08< celticminstrel> I dunno how unordered_map uses it though.
20161201 05:59:46< tad_carlucci> Which will be mod'd to table size. Excessive collisions will cause a table expansion. To avoid that you'll need a 2T table or so. Probably not what you want to hold just a few dozen values :P
20161201 06:00:01< celticminstrel> Fair enough, I guess.
20161201 06:00:51< celticminstrel> vultraz: IIRC you need to include <utility> for std::hash
20161201 06:01:07< tad_carlucci> Basically what I'm saying is trust the STL. Use the 32-bit rgba value and accept a bit of lagginess (probably never noticable) every now and then.
20161201 06:10:13< vultraz> celticminstrel: http://pastebin.com/YAuFqvvA
20161201 06:10:40< celticminstrel> Seems fine?
20161201 06:10:56< celticminstrel> Oh wait, it should probably return size_t not uint32_t,.
20161201 06:11:34-!- 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.]
20161201 06:12:16< vultraz> hmm
20161201 06:12:24< vultraz> i just realized recolor_range returns map
20161201 06:12:32< vultraz> so i can't use unordered_map
20161201 06:12:54< vultraz> unless i change that..
20161201 06:13:47< vultraz> :|
20161201 06:16:56< vultraz> and i assume a map cannot be turned into an unordered map
20161201 06:16:57< celticminstrel> Why can't you change that?
20161201 06:17:50< vultraz> ehh
20161201 06:17:53< vultraz> I suppose I could
20161201 06:18:01< vultraz> the code ends up in recolor_image anyway
20161201 06:18:59< vultraz> is unordered_map more efficient?
20161201 06:20:47< vultraz> ie, when you have
20161201 06:20:49< vultraz> 				std::map<Uint32, Uint32>::const_iterator i = map_rgb.find(oldrgb);
20161201 06:20:50< vultraz> 				if(i != map_rgb.end()){
20161201 06:20:52< vultraz> 					*beg = (alpha << 24) + i->second;
20161201 06:20:53< vultraz> 				}
20161201 06:20:59< vultraz> and yes, I need to rewrite this bloody code too..
20161201 06:23:03< aeth> that breaks in my IRC client (but works fine in the logs, for some reason)
20161201 06:23:10< aeth> I hate tabs. :p
20161201 06:23:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 06:24:09< celticminstrel> map is O(n log n) lookup IIRC correctly, both in average and worst case.
20161201 06:24:30< celticminstrel> Or log n.
20161201 06:24:37< celticminstrel> Was it log n?
20161201 06:25:24< celticminstrel> Okay yeah, O(log n).
20161201 06:25:33< celticminstrel> unordered_map is O(n) in worst case.
20161201 06:25:40< celticminstrel> But generally it's O(1).
20161201 06:26:04< celticminstrel> Worst case would be if every key had the same hash, for reference.
20161201 06:26:17< celticminstrel> So if your hash was "return 0" you'd be getting O(n) lookup.
20161201 06:26:39< celticminstrel> 1 is better than log n which is better than n, so ...
20161201 06:26:54< celticminstrel> unordered_map is generally faster, but occasionally slower.
20161201 06:27:16< celticminstrel> (By "lookup" I mean the find function. Or operator[] which just uses find internally.)
20161201 06:27:26-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161201 06:28:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161201 06:43:54< irker507> wesnoth: Celtic Minstrel wesnoth:maybe_fix_travis e5b44c52e903 / / (10 files in 5 dirs): Attempt to fix Travis, Part the Third https://github.com/wesnoth/wesnoth/commit/e5b44c52e90321cb9aa43e5ca9c8f77ac1ab34f0
20161201 06:43:56< irker507> wesnoth: Celtic Minstrel wesnoth:maybe_fix_travis 373826925c83 / src/gettext_boost.cpp: Fix/suppress some (mostly MSVC) warnings in gettext_boost.cpp https://github.com/wesnoth/wesnoth/commit/373826925c834de9c8164fbb1100c1eb8fdb6716
20161201 06:52:08-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20161201 06:54:13< vultraz> please don't merge that until im done
20161201 06:57:01-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 06:57:47< vultraz> which will probably be awhile
20161201 07:00:28< celticminstrel> It'll likely conflict.
20161201 07:00:42< celticminstrel> Is awhile today?
20161201 07:01:06< aeth> What are you working on? I tried reading far back in the logs and couldn't get enough context
20161201 07:14:44< vultraz> refactoring color_range
20161201 07:16:03-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161201 07:16:04-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161201 07:37:34< vultraz> gahh
20161201 07:37:40< vultraz> soooo much needs to be changed :|
20161201 07:39:01< vultraz> then again, this is probably the last big thing to refactor
20161201 07:46:03< vultraz> 			Uint32 oldrgb = (*beg) & 0x00FFFFFF;
20161201 07:46:04< vultraz> 			auto i = map_rgb.find(color_t::from_argb_bytes(oldrgb));
20161201 07:46:06< vultraz> 			if(i != map_rgb.end()){
20161201 07:46:08< vultraz> 				*beg = (alpha << 24) + (i->second >> 8);
20161201 07:46:09< vultraz> 			}
20161201 07:46:11< vultraz> would this work>
20161201 07:46:53-!- travis-ci [~travis-ci@ec2-54-90-108-235.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 07:46:54< travis-ci> wesnoth/wesnoth#12246 (master - 6054ad3 : Charles Dang): The build is still failing.
20161201 07:46:54< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180287129
20161201 07:46:54-!- travis-ci [~travis-ci@ec2-54-90-108-235.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 07:49:56< JyrkiVesterinen> What's the type of map_rgb?
20161201 07:50:28< vultraz>  std::unordered_map<color_t, color_t>;
20161201 07:51:10< JyrkiVesterinen> In that case, bit-shifting the i->second (which is a color_t) doesn't make sense.
20161201 07:51:34< JyrkiVesterinen> Neither does adding it to alpha << 24 which is an integer.
20161201 07:53:20< JyrkiVesterinen> If *beg is an uint32_t and stores a color as ARGB, something like this would work: *beg = (alpha << 24) | i->second.to_rgba_bytes()
20161201 07:53:41< vultraz> oh right, I need to_*_bytes..
20161201 07:54:03< vultraz> beg is Uint32* beg = lock.pixels();
20161201 07:54:04< JyrkiVesterinen> That's assuming that i->second has an alpha of zero. If its alpha can be nonzero, you need to get rid of that.
20161201 07:54:12< vultraz> an SDL_Surface's underlying pixel matrix
20161201 07:55:05< vultraz> and yes, I think the alpha would be 0...
20161201 07:55:11< vultraz> (and do you mean argb_bytes?)
20161201 07:55:20< JyrkiVesterinen> Yes, I do. I mixed them up.
20161201 07:55:33< celticminstrel> Technically an SDL_Surface's pixels can be in almost any format imaginable... but I think Wesnoth uses only RGBA?
20161201 07:56:05< celticminstrel> Wait, was it ARGB?
20161201 07:56:15< vultraz> 			// Palette use only RGB channels, so remove alpha
20161201 07:56:17< vultraz> 			Uint32 oldrgb = (*beg) & 0x00FFFFFF;
20161201 07:56:34< celticminstrel> So it's assuming ARGB.
20161201 07:57:11< vultraz> well it's stripping alpha
20161201 07:57:15< vultraz> so it's essentially RGB
20161201 07:57:30< celticminstrel> 0RGB, yes.
20161201 07:57:52 * celticminstrel assumes that RGB0 is also a possibility that exists.
20161201 07:58:18< celticminstrel> Pretty sure there are also uneven ones, where the channels aren't all the same size.
20161201 07:58:31< celticminstrel> ...but that's totally irrelevant here.
20161201 07:59:50< vultraz> now I need to update stuff in game_config...
20161201 07:59:52< vultraz> the fun never ends :|
20161201 07:59:59< celticminstrel> :)
20161201 08:00:11< vultraz> and I haven't tried building once :P
20161201 08:00:30< celticminstrel> Oh my.
20161201 08:01:45< vultraz> SO MUCH TO UPDATE
20161201 08:02:47-!- htee [~htee@dtcqfkyf8l28h1mh9512t-3.rev.dnainternet.fi] has joined #wesnoth-dev
20161201 08:04:39< vultraz> ok, color_info..
20161201 08:04:44< vultraz> what is this even doing..
20161201 08:05:19< vultraz> I guess I need from_hex_string?
20161201 08:05:30< celticminstrel> No idea!
20161201 08:05:47< vultraz> team_rgb_colors...
20161201 08:05:55< vultraz> std::map<std::string, std::vector<uint32_t> >
20161201 08:07:25< vultraz> ok, let's tackle add_color_info
20161201 08:12:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 08:12:12< vultraz> fuck it, let's build and fix as we go.
20161201 08:12:34< celticminstrel> That's usually what I do.
20161201 08:13:09-!- nik_ [db591e84@gateway/web/freenode/ip.219.89.30.132] has joined #wesnoth-dev
20161201 08:14:03-!- atarocch [~atarocch@natmobil.sfa.se] has joined #wesnoth-dev
20161201 08:16:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20161201 08:26:38< vultraz> 	for(const auto& cm : cmap) {
20161201 08:26:40< vultraz> 		clist.insert(cm.second);
20161201 08:26:41< vultraz> 	}
20161201 08:26:45< vultraz> so this is where color_range::operator< was needed :|
20161201 08:26:55< celticminstrel> What's clist?
20161201 08:27:32< vultraz> a set
20161201 08:27:57< celticminstrel> Well, you could use unordered_set then. Of course that would mean color_range needs a hash, though.
20161201 08:28:05< celticminstrel> And that's not as easy as a hash for color_t.
20161201 08:28:48< vultraz> :|
20161201 08:28:59< vultraz> fuck
20161201 08:29:07< vultraz> ok you know what
20161201 08:29:09< vultraz> I know what to do
20161201 08:29:51< celticminstrel> Oh right, color_range was only four colours... not a whole list.
20161201 08:30:02< celticminstrel> Still harder than for color_t though, because you have 128 bits there.
20161201 08:30:10< celticminstrel> And it needs to be squashed into 64 bits.
20161201 08:30:35-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 08:30:36< travis-ci> wesnoth/wesnoth#12247 (master - dcbf25e : Charles Dang): The build is still failing.
20161201 08:30:36< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180290372
20161201 08:30:36-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 08:30:59< celticminstrel> It's probably terrible, but you could try something like ((mid_ ^ rep_) << 32) | (max_ ^ min_)
20161201 08:31:16< vultraz> 		if(mid_ != b.mid()) { return mid_.to_rgba_bytes() < b.mid().to_rgba_bytes(); }
20161201 08:31:18< vultraz> 		if(max_ != b.max()) { return max_.to_rgba_bytes() < b.max().to_rgba_bytes(); }
20161201 08:31:19< vultraz> 		if(min_ != b.min()) { return min_.to_rgba_bytes() < b.min().to_rgba_bytes(); }
20161201 08:31:21< vultraz> 		return(rep_.to_rgba_bytes() < b.rep().to_rgba_bytes());
20161201 08:31:34< celticminstrel> Yes, that's a lexicographical compare.
20161201 08:31:51< celticminstrel> [Dec 01@03:29:09am] vultraz: I know what to do
20161201 08:31:53< celticminstrel> ?
20161201 08:32:09< vultraz> yes, the above
20161201 08:32:23< celticminstrel> Oh right, so you're comparing them as numbers lexicographically.
20161201 08:35:02< vultraz> oh wait
20161201 08:35:07< vultraz> it's color_t that need operator<
20161201 08:35:26< vultraz> blah, lexicographical directly!
20161201 08:35:27< celticminstrel> Why?
20161201 08:35:41< celticminstrel> Why does color_t need operator<?
20161201 08:36:24< vultraz> it's a set of color_t
20161201 08:36:26< vultraz> for some reason
20161201 08:36:35< celticminstrel> So make it unordered_set.
20161201 08:36:36-!- Rhonda [~rhonda@wesnoth/developer/rhonda] has quit [Ping timeout: 260 seconds]
20161201 08:36:43< vultraz> don't ask me, I didn't write this function
20161201 08:37:54-!- Rhonda [~rhonda@anguilla.debian.or.at] has joined #wesnoth-dev
20161201 08:40:09< vultraz> at some point I should figure out why every single big change causes a rebuild of stuff in ai/
20161201 08:40:30< vultraz> and actions/
20161201 08:40:35< vultraz> it always starts with actions/heal.*cpp
20161201 08:40:38< vultraz> pp*
20161201 08:40:42< celticminstrel> Wow, I just had to Ctrl-Alt-Del MSVC because it couldn't even exit due to some out of memory error.
20161201 08:41:05< celticminstrel> (Might have something to do with it having been sitting open for weeks or months.)
20161201 08:42:17< vultraz> why does this file include game_display..
20161201 08:42:22< vultraz> and game_board
20161201 08:44:04< vultraz> in the F's
20161201 08:46:09< vultraz> anddd back to A
20161201 08:46:25< celticminstrel> ???
20161201 08:46:34< celticminstrel> Are you complaining about headers not being sorted?
20161201 08:46:34< vultraz> compiler progress
20161201 08:46:48< vultraz> no, I edited a header
20161201 08:46:55< vultraz> and it makes stuff rebuild
20161201 08:46:58< celticminstrel> Oh, it probably goes according to sorted full path.
20161201 08:47:38< vultraz> I swear, at least 50% of programming is waiting on a compiler
20161201 08:50:13< celticminstrel> Depends on the language though. :P
20161201 08:50:49< vultraz> true
20161201 08:50:59< vultraz> non-compiled languages, so much fastr
20161201 08:51:01< vultraz> faster
20161201 08:51:21< vultraz> then again, you don't have the "it's compiling" excuse for not doing anything
20161201 08:52:50< celticminstrel> You could have "it's computing" as an excuse (depending what you're doing).
20161201 08:55:01< JyrkiVesterinen> "I'm testing if I broke anything"
20161201 08:55:30< vultraz> :P
20161201 08:59:30-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 08:59:31< travis-ci> wesnoth/wesnoth#12248 (master - 80c372b : Charles Dang): The build is still failing.
20161201 08:59:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180298153
20161201 08:59:31-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 09:13:23< irker507> wesnoth: Jyrki Vesterinen wesnoth:master 49155fadd678 / utils/appveyor/irc-notify.py: AppVeyor IRC notification: prefix channel name with # when joining https://github.com/wesnoth/wesnoth/commit/49155fadd678abb3f71162b7e414ae283c0418c5
20161201 09:13:54< celticminstrel> So all this time we were sending messages to a nonexistent "wesnoth-appveyor-status" user? :O
20161201 09:14:28< JyrkiVesterinen> No. Attempting to send external messages to that channel.
20161201 09:14:29< celticminstrel> Incidentally, is the build failure affecting AppVeyor too, or is it just Travis?
20161201 09:14:50< celticminstrel> Ah, so it failed to join but then sent the message properly.
20161201 09:14:56< JyrkiVesterinen> I created that channel to test if IRC notifications work before redirecting the notifications here.
20161201 09:15:23< JyrkiVesterinen> Yes, build failure affects AppVeyor too.
20161201 09:15:50< JyrkiVesterinen> MSVC doesn't build wesnothlib separately.
20161201 09:16:08< celticminstrel> No idea yet if my attempt has fixed Travis... it hasn't even started building...
20161201 09:16:26< celticminstrel> Once it works I'll squash and merge.
20161201 09:16:28< JyrkiVesterinen> SDL is found when compiling game_config.cpp (which #includes color.hpp) as part of wesnothd.
20161201 09:16:42< JyrkiVesterinen> But then linking fails because color.cpp wasn't compiled.
20161201 09:17:16< celticminstrel> My fix includes that.
20161201 09:17:31< celticminstrel> (BTW it's kinda not great for AppVeyor to only build master...)
20161201 09:17:39< celticminstrel> (Better than nothing at all though, at least.)
20161201 09:18:18< JyrkiVesterinen> I know. I was hoping that Travis would verify the fix and I or you would merge the branch before the ~8:00 UTC AppVeyor builds started.
20161201 09:18:40< celticminstrel> Eh?
20161201 09:18:41< JyrkiVesterinen> Nevertheless, at least I got to know that the notification script didn't work.
20161201 09:19:23< JyrkiVesterinen> I mean that I hoped that your build fix would be in master in time for the AppVeyor builds which just finished.
20161201 09:32:09-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161201 09:41:36-!- nik_ [db591e84@gateway/web/freenode/ip.219.89.30.132] has quit [Ping timeout: 260 seconds]
20161201 10:00:24-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20161201 10:00:24-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20161201 10:00:24-!- VultCave is now known as vultraz
20161201 10:00:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 10:04:24-!- Yaiyan [~yaiyan@46.101.48.31] has quit [Ping timeout: 260 seconds]
20161201 10:04:24-!- abruanese [~a@45.63.76.107] has quit [Ping timeout: 260 seconds]
20161201 10:04:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20161201 10:04:59-!- abruanese [~a@45.63.76.107] has joined #wesnoth-dev
20161201 10:06:52-!- yaiyan [~yaiyan@46.101.48.31] has joined #wesnoth-dev
20161201 10:14:07-!- travis-ci [~travis-ci@ec2-54-197-173-204.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 10:14:08< travis-ci> wesnoth/wesnoth#12250 (master - 3dc2fa9 : Jyrki Vesterinen): The build is still failing.
20161201 10:14:08< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180299711
20161201 10:14:08-!- travis-ci [~travis-ci@ec2-54-197-173-204.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 10:29:06< vultraz> build successful :D
20161201 10:29:43< vultraz> sadly I broke TC-ing completely :P
20161201 10:31:16-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20161201 10:32:39-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161201 10:33:56-!- vultraz [~chatzilla@124.109.10.167] has quit [Read error: Connection reset by peer]
20161201 10:34:10-!- VultCave is now known as vultraz
20161201 10:34:24-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20161201 10:34:25-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161201 10:39:09-!- Netsplit *.net <-> *.split quits: TC02, _laco
20161201 10:42:04< Rhonda> huhm
20161201 10:43:37-!- Netsplit over, joins: TC02
20161201 10:44:30< irker507> wesnoth: Charles Dang wesnoth:master f2ab245e8d3f / src/ (20 files in 5 dirs): Refactor color_range to use color_t https://github.com/wesnoth/wesnoth/commit/f2ab245e8d3f782911bcd6e83b0d34514331db42
20161201 10:44:51< vultraz> TC-ing currently broken, need some help to fix :/
20161201 10:45:20< vultraz> it's possible because the std::hash specification uses to_rgba_bytes...
20161201 10:45:46< vultraz> but here, I'm searching from from_argb_bytes..? though that shouldn't matter
20161201 10:45:50< vultraz> (or should it?)
20161201 10:46:27< JyrkiVesterinen> Std::unordered_map works as long as the same value always returns the same hash.
20161201 10:46:47< JyrkiVesterinen> (It becomes slow if different values give the same hash, but continues to work.)
20161201 10:47:15< JyrkiVesterinen> It isn't possible for the std::hash implementation to be the problem here.
20161201 10:47:21< vultraz> I see
20161201 10:47:42< vultraz> well, somehow the actual recoloring part of recolor_image never seems to be reached
20161201 10:48:01< vultraz> ie, the *beg = (alpha << 24) | i->second.to_argb_bytes(); line
20161201 10:49:00-!- _laco [~laco@static.183.80.201.138.clients.your-server.de] has joined #wesnoth-dev
20161201 10:55:45< JyrkiVesterinen> OK, I found the problem. Your code removes alpha in a wrong way.
20161201 10:55:58< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/commit/f2ab245e8d3f782911bcd6e83b0d34514331db42#diff-d144f1595392c98740a701fe2658f09dR1079
20161201 10:56:16< JyrkiVesterinen> In map_rgb, every color has an alpha of 255 (opaque).
20161201 10:56:17< vultraz> ah, I hadn't touched that line..
20161201 10:56:27< JyrkiVesterinen> The AND in that line sets alpha to zero instead.
20161201 10:56:27< vultraz> I see
20161201 10:56:48< vultraz> so should I just remove that?
20161201 10:57:43< JyrkiVesterinen> It depends on what the existing alpha value is in *beg. If it's always 255, removing the alpha is the way to go.
20161201 10:58:24< JyrkiVesterinen> Otherwise you need to manually set alpha to 255, for example with "| 0xFF000000".
20161201 10:59:19< JyrkiVesterinen> Also, you need to mask out the alpha bytes in the OR in line 1083. Otherwise every pixel will be fully opaque.
20161201 11:00:57< vultraz> hm..
20161201 11:01:09< vultraz> I'm not sure it's always 255
20161201 11:01:13< vultraz> in fact it's probably not
20161201 11:02:55< vultraz> hm..
20161201 11:03:09< vultraz> I thought *beg = (alpha << 24) | (i->second.to_argb_bytes() << 8); would do that last thing but it seems not 
20161201 11:04:24< JyrkiVesterinen> Shifting the ARGB value left by 8 bits indeed removes the alpha, but it also swaps the meanings of color channels. Red becomes alpha, green becomes red, blue becomes green.
20161201 11:04:34< vultraz> oh
20161201 11:04:49< vultraz> so what would I do?
20161201 11:05:04< JyrkiVesterinen> *beg = (alpha << 24) | (i->second.to_argb_bytes() & 0x00FFFFFF);
20161201 11:05:49< vultraz> ahhh
20161201 11:05:53< vultraz> that works
20161201 11:05:55< vultraz> thanks :D
20161201 11:06:00< vultraz> surprisingly simple fix
20161201 11:06:01< JyrkiVesterinen> Yw :)
20161201 11:11:18< irker507> wesnoth: Charles Dang wesnoth:master 00b9d6e69147 / src/sdl/utils.cpp: Fixup f2ab245e8d3f via feedback https://github.com/wesnoth/wesnoth/commit/00b9d6e691470af187a9146da7219cf64b2d7781
20161201 11:11:21< irker507> wesnoth: Charles Dang wesnoth:master 58fecf8b5486 / src/ (13 files in 5 dirs): Bunch of include cleanups https://github.com/wesnoth/wesnoth/commit/58fecf8b5486d8394c7d64d03e80473fd2a92d12
20161201 11:12:09< vultraz> I'm actually rather surprised my code seems to have hit quite close to correct the first time
20161201 11:15:24< irker507> wesnoth: Charles Dang wesnoth:master a97c5edccdff / src/storyscreen/render.cpp: Storyscreen: convert two color constants to color_t https://github.com/wesnoth/wesnoth/commit/a97c5edccdffcf018ef8a7625f85801e7f36c432
20161201 11:24:11-!- yaiyan is now known as Yaiyan
20161201 11:35:28-!- gimemor [~gimemor@host-95-152-34-56.dsl.sura.ru] has quit [Ping timeout: 268 seconds]
20161201 11:42:09-!- travis-ci [~travis-ci@ec2-54-197-173-204.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 11:42:10< travis-ci> wesnoth/wesnoth#12254 (maybe_fix_travis - 3738269 : Celtic Minstrel): The build passed.
20161201 11:42:11< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180315967
20161201 11:42:11-!- travis-ci [~travis-ci@ec2-54-197-173-204.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 11:47:42-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161201 11:47:56-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 11:48:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 11:51:22-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161201 11:53:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20161201 11:53:16-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 11:55:11-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161201 11:58:49-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 12:01:43-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161201 12:02:04-!- travis-ci [~travis-ci@ec2-54-197-173-204.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 12:02:05< travis-ci> wesnoth/wesnoth#12255 (master - 49155fa : Jyrki Vesterinen): The build is still failing.
20161201 12:02:05< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180338818
20161201 12:02:05-!- travis-ci [~travis-ci@ec2-54-197-173-204.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 12:05:16-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161201 12:11:35-!- Bonobo [~Bonobo@2001:44b8:254:3200:5421:9897:7424:da0] has quit [Quit: Leaving]
20161201 12:19:56-!- Duthlet [~Duthlet@dslb-146-060-035-062.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20161201 12:46:47-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 12:46:48< travis-ci> wesnoth/wesnoth#12256 (master - f2ab245 : Charles Dang): The build is still failing.
20161201 12:46:48< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180357540
20161201 12:46:48-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 12:56:30-!- nik_ [db591e84@gateway/web/freenode/ip.219.89.30.132] has joined #wesnoth-dev
20161201 13:07:34< irker507> wesnoth: Celtic Minstrel wesnoth:master e7e5ca5fa2d4 / / (50 files in 15 dirs): Fix Travis https://github.com/wesnoth/wesnoth/commit/e7e5ca5fa2d4b5802d98baad2c1baaf802ebd57e
20161201 13:08:02< nik_> imagine this channel irl, 40 people sit in a room and watch 3 people talk about coding lol
20161201 13:08:05< JyrkiVesterinen> (Note: I merged and pushed that commit.)
20161201 13:08:40< JyrkiVesterinen> nik_: most IRC rooms are like this.
20161201 13:11:52-!- Duthlet [~Duthlet@dslb-146-060-035-062.146.060.pools.vodafone-ip.de] has quit [Ping timeout: 250 seconds]
20161201 13:12:28< Soliton> and then imagine they sit in 10 other rooms as well.
20161201 13:17:00< DeFender1031> nik_, ever been to a panel discussion? "40 people sit in a room and watch 3 people talk about coding" pretty much sums that up.
20161201 13:17:40-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 13:17:41< travis-ci> wesnoth/wesnoth#12257 (master - 58fecf8 : Charles Dang): The build is still failing.
20161201 13:17:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180363810
20161201 13:17:41-!- travis-ci [~travis-ci@ec2-54-205-14-69.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 13:18:19< DeFender1031> nik_, the funny part would be that some dude named travis bursts into the room every so often, yells "The build is failing!" and then leaves without another word, while the panelists go one with their discussion as if nothing had happened.
20161201 13:18:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161201 13:20:08< Soliton> i'd say the last part is more sad than funny. :->
20161201 13:23:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 248 seconds]
20161201 13:24:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161201 13:32:55-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161201 13:36:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 13:36:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20161201 13:36:59-!- htee [~htee@dtcqfkyf8l28h1mh9512t-3.rev.dnainternet.fi] has quit [Quit: Leaving...]
20161201 13:40:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161201 13:43:34-!- travis-ci [~travis-ci@ec2-54-197-173-204.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 13:43:35< travis-ci> wesnoth/wesnoth#12258 (master - a97c5ed : Charles Dang): The build is still failing.
20161201 13:43:35< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180364976
20161201 13:43:35-!- travis-ci [~travis-ci@ec2-54-197-173-204.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 13:48:42-!- stikonas_ is now known as stikonas
20161201 14:00:52< nik_> lol
20161201 14:01:38< nik_> idk if its a good analogy, in a panel theyre talking for the audience, here theyre talking to each other and we're just watching silently
20161201 14:02:18< nik_> is there a place to find all the different chat rooms
20161201 14:03:08< DeFender1031> nik_, fair. Though I still think the part about travis is funny.
20161201 14:16:33< Soliton> nik_: /msg alis help
20161201 14:23:02-!- gimemor [~gimemor@host-95-152-34-56.dsl.sura.ru] has joined #wesnoth-dev
20161201 14:33:37-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161201 14:38:28-!- travis-ci [~travis-ci@ec2-54-90-108-235.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 14:38:29< travis-ci> wesnoth/wesnoth#12259 (master - e7e5ca5 : Celtic Minstrel): The build has errored.
20161201 14:38:29< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180389585
20161201 14:38:29-!- travis-ci [~travis-ci@ec2-54-90-108-235.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 14:39:11< nik_> hey i said lol :)
20161201 14:39:25< nik_> soliton what u trying to do there
20161201 14:40:16-!- astrelyon [~astrelyon@dh207-111-195.xnet.hr] has quit [Ping timeout: 250 seconds]
20161201 14:42:11< JyrkiVesterinen> Hmm. Latest build succeeded otherwise, but this change had broken build of tests in the meantime: https://github.com/wesnoth/wesnoth/commit/f2ab245e8d3f782911bcd6e83b0d34514331db42#diff-55e83a21373b741ccc953befc8ccbefcR169
20161201 14:42:35< JyrkiVesterinen> I'm not going to fix it. I only needed to fix things to the point that the MSVC builds pass.
20161201 15:23:17-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161201 15:32:15< irker507> wesnoth: Charles Dang wesnoth:master f434be7baa0f / projectfiles/CodeBlocks/wesnoth.cbp: Update CB projectfile https://github.com/wesnoth/wesnoth/commit/f434be7baa0f53e60ceb65837eb9cefbb4a443e3
20161201 15:32:18< irker507> wesnoth: Charles Dang wesnoth:master 12c57a750ff7 / src/ (17 files in 6 dirs): Cleaned up marked-up_text.hpp includes https://github.com/wesnoth/wesnoth/commit/12c57a750ff700c4ae02de1a81d5adce265b24b0
20161201 15:33:23< celticminstrel> Kinda wanted a more detailed commit message for that. Oh well.
20161201 15:33:42< celticminstrel> Glad it worked, though.
20161201 15:33:46< vultraz> Can you fix travis again? :P
20161201 15:34:19< celticminstrel> (Also the gettext_boost commit should've probably been kept separate.)
20161201 15:34:26< JyrkiVesterinen> vultraz: The way to skip Travis builds is [ci skip] and not [ci_skip].
20161201 15:34:32< vultraz> D:
20161201 15:34:34< vultraz> oh well
20161201 15:35:27< celticminstrel> What's wrong with Travis now? :|
20161201 15:35:49< vultraz> [01:42:10]	JyrkiVesterinen	Hmm. Latest build succeeded otherwise, but this change had broken build of tests in the meantime: https://github.com/wesnoth/wesnoth/commit/f2ab245e8d3f782911bcd6e83b0d34514331db42#diff-55e83a21373b741ccc953befc8ccbefcR169
20161201 15:41:36-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161201 15:41:42-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161201 15:51:34-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161201 15:54:01< celticminstrel> 00b9d6e confused me for a minute (why change & to |)... but I guess the idea is that instead of removing the alpha you're forcing it opaque.
20161201 15:56:30< celticminstrel> vultraz: Where are your Boost headers?
20161201 15:57:41< JyrkiVesterinen> Exactly. Alpha needs to be forced to opaque (255) and not transparent (0) so that the color is found from the map.
20161201 15:59:55-!- JyrkiVesterinen [~JyrkiVest@87-100-135-132.bb.dnainternet.fi] has quit [Quit: Going somewhere]
20161201 16:27:15< vultraz> celticminstrel: ?
20161201 16:27:23< celticminstrel> Never mind.
20161201 16:31:33-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Ping timeout: 248 seconds]
20161201 16:32:31-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20161201 16:37:33-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161201 16:38:21< tad_carlucci> Are still still at an unbuildable state for master?
20161201 16:54:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 16:57:52< celticminstrel> vultraz: Please try this: http://celmin.pwcsite.com/wesnoth/tests.cbp
20161201 16:58:12< celticminstrel> Probably needs a little tweaking.
20161201 16:58:59< celticminstrel> Also naturally assumes that you have all of Boost, not cherry-picked Boost.
20161201 16:59:21< celticminstrel> I think I forgot to remove wesnoth.cpp too.
20161201 16:59:44-!- Appleman1234 [~Appleman1@KD106161214141.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20161201 17:05:47< Soliton> nik_: you can use alis to find channels.
20161201 17:06:17< tad_carlucci>   ..\..\src\color.cpp(74): error C2398: Element '4': conversion from 'const uint32_t' to 'uint8_t' requires a narrowing conversion [C:\projects\wesnoth\projectfiles\VC14\wesnothlib.vcxproj]
20161201 17:30:45-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161201 17:31:13-!- gfgtdf [~chatzilla@x4e36900c.dyn.telefonica.de] has joined #wesnoth-dev
20161201 17:31:37-!- JyrkiVesterinen [~JyrkiVest@89-166-118-169.bb.dnainternet.fi] has joined #wesnoth-dev
20161201 17:36:42-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161201 17:43:13-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 17:51:02-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161201 17:55:02-!- 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.]
20161201 18:14:35-!- prkc [~prkc@46.166.188.222] has joined #wesnoth-dev
20161201 18:16:41-!- nik_ [db591e84@gateway/web/freenode/ip.219.89.30.132] has quit [Ping timeout: 260 seconds]
20161201 18:17:36-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161201 18:21:22< tad_carlucci> JyrkiVesterinen, I question whether an error in the Pyhton for IRC notifications should cause the CI build to be marked as failed.
20161201 18:21:51< JyrkiVesterinen> Is there an error there?
20161201 18:22:28< JyrkiVesterinen> I am in the #wesnoth-appveyor-status channel, and I got the notification about the latest build succeeding.
20161201 18:22:34-!- atarocch [~atarocch@natmobil.sfa.se] has quit [Ping timeout: 265 seconds]
20161201 18:22:38< tad_carlucci> https://ci.appveyor.com/project/GregoryLundberg/wesnoth-w2x2j/build/Wesnoth-VS2015-master-36/job/6ktw4r9y85emufcw
20161201 18:23:03< tad_carlucci> Cool. I tried that but didn't.
20161201 18:23:25< JyrkiVesterinen> It was sent as a channel notice, mind you. At least my IRC client gives a visible+annoying notification on channel notices, and I'll need to get rid of that.
20161201 18:23:52 * tad_carlucci nod.
20161201 18:24:09< JyrkiVesterinen> Unfortunately I can't find the way to send regular channel messages in the IRC specification ( https://tools.ietf.org/html/rfc1459 ) for the life of me... :x
20161201 18:24:48< JyrkiVesterinen> Private messages and notices (which is what the script currently sends) I did find, but not regular messages.
20161201 18:24:52< tad_carlucci> I'm presuming that when it's all done and we're all happy and appveyor is set up for master like travis, you're going to move the IRC messages
20161201 18:25:05< tad_carlucci> Ah
20161201 18:26:33< JyrkiVesterinen> I looked at your log. I figure I'll need to make the script ignore exceptions.
20161201 18:26:50< JyrkiVesterinen> I'll do it after I have figured out how to send channel messages.
20161201 18:27:40< tad_carlucci> I saw a github project link for it .. don't remember where .. someplace linked from the appveyor issue asking for IRC, I think,.
20161201 18:29:02< JyrkiVesterinen> I think it's the same link I saw.
20161201 18:29:44< tad_carlucci> probably so
20161201 18:30:00< JyrkiVesterinen> https://github.com/nexB/scancode-toolkit/blob/develop/etc/scripts/irc-notify.py
20161201 18:30:28< JyrkiVesterinen> I took that script and started implementing the "join the channel instead of sending an external notice" feature.
20161201 18:30:37 * tad_carlucci nods.
20161201 18:30:44< JyrkiVesterinen> External notices aren't allowed in #wesnoth-dev, and rightly so.
20161201 18:31:16< tad_carlucci> Well, if all else fails I s'pose you could look at the C/C++ source for a normal client and see how it's done
20161201 18:32:10< celticminstrel> JyrkiVesterinen: Regular messages are PRIVMSG
20161201 18:32:25-!- irker507 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161201 18:32:38< celticminstrel> The difference from an actual private message is just the target.
20161201 18:32:56< JyrkiVesterinen> OK. I thought it was a possibility.
20161201 18:33:13< JyrkiVesterinen> It's just that the specification seems to suggest otherwise: "The difference
20161201 18:33:13< JyrkiVesterinen>    between NOTICE and PRIVMSG is that automatic replies must never be
20161201 18:33:13< JyrkiVesterinen>    sent in response to a NOTICE message."
20161201 18:33:37< JyrkiVesterinen> *The* difference. Suggesting that there aren't any other differences.
20161201 18:33:50< celticminstrel> I'm pretty sure clients are forced to violate that, too.
20161201 18:33:54< JyrkiVesterinen> I'll change the script to use PRIVMSG.
20161201 18:34:02< celticminstrel> Because ChanServ always sends NOTICE and clients need to respond to that.
20161201 18:34:25 * celticminstrel has an active IRC bot, so that's why I know this stuff.
20161201 18:35:52< JyrkiVesterinen> Is the receiver string #channelname like with NOTICE?
20161201 18:35:57< celticminstrel> Yeah.
20161201 18:36:12< celticminstrel> In both PRIVMSG and NOTICE, the lack of # indicates the target is a specific user.
20161201 18:47:33-!- irker804 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161201 18:47:33< irker804> wesnoth: Jyrki Vesterinen wesnoth:master 8cfd12854353 / utils/appveyor/irc-notify.py: AppVeyor IRC notification: send message with PRIVMSG https://github.com/wesnoth/wesnoth/commit/8cfd12854353ba4c6d36ef85be31538cb0ca1363
20161201 18:47:33< irker804> wesnoth: Jyrki Vesterinen wesnoth:master 19167ca3be60 / utils/appveyor/irc-notify.py: Don't fail the build if sending the IRC notification fails https://github.com/wesnoth/wesnoth/commit/19167ca3be601695db408d04edf1177c01ddde0f
20161201 18:57:31-!- Shiki [~Shiki@141.57.60.11] has joined #wesnoth-dev
20161201 19:00:09< tad_carlucci> JyrkiVesterinen, My project name has a space. The link in the IRC is short due to that so gets a not-found when I click it
20161201 19:01:48< JyrkiVesterinen> Okay. I hadn't tried clicking the links.
20161201 19:01:59< JyrkiVesterinen> Should be easy to fix with some URL encoding.
20161201 19:02:39< tad_carlucci> Also, might be good to include the build target (Release vs Debug) since I see both messages.
20161201 19:03:23< tad_carlucci> I s'pose for 'live' on wesnoth-dev we'd only want one run instead of the 4 I have set up.
20161201 19:09:37< JyrkiVesterinen> I had initially planned to just show all messages here. 12 messages per 24 hours doesn't sound unacceptable to me.
20161201 19:10:46< JyrkiVesterinen> With "one run", do you mean that only one configuration is built (and not that all four are built, but only one sends the notification)?
20161201 19:11:33< JyrkiVesterinen> At least I'd prefer to just reduce the number of built configurations. No one will look at build configurations which don't send notifications.
20161201 19:11:55< tad_carlucci> I have two projects: 2013 and 2015 and do a 'matrix' of two build runs per.
20161201 19:12:58< tad_carlucci> I could not see how to do the 13/15 switch in the same matrix. It's probably do-able I just didn't see it.
20161201 19:13:59< JyrkiVesterinen> We have two projects right now, and it's a good enough setup IMHO.
20161201 19:14:10-!- atarocch [~atarocch@host-78-65-187-41.homerun.telia.com] has joined #wesnoth-dev
20161201 19:14:11< tad_carlucci> I have my projects set to run on any push, same as travis.
20161201 19:14:27< JyrkiVesterinen> Mine are scheduled to build every 8 hours.
20161201 19:14:57< JyrkiVesterinen> I initially used the default of building on every push, but it didn't work. Automatic builds weren't triggered at all.
20161201 19:15:02< tad_carlucci> Which sounds fine to me, too. Might be able to suppress the runs if no pushes where made .. I think I saw something about that but wasn't paying attention
20161201 19:16:17< tad_carlucci> Maybe, someday, we can extend the Release build to make a install kit and do a 'nightly build' thing.
20161201 19:22:56-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161201 19:35:41-!- iceiceice [~chris@unaffiliated/iceiceice] has left #wesnoth-dev ["Ex-Chat"]
20161201 19:54:43-!- Kwandulin [~Miranda@p200300760F6EBFA9EC892BCF51037504.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161201 19:55:49-!- gimemor [~gimemor@host-95-152-34-56.dsl.sura.ru] has quit [Ping timeout: 248 seconds]
20161201 19:56:53< celticminstrel> Should we remove the Perl wmlxgettext?
20161201 19:57:42< tad_carlucci> Is there any other Perl?
20161201 19:59:08< celticminstrel> https://github.com/wesnoth/wesnoth/search?l=perl
20161201 20:00:03< tad_carlucci> Is someone working on fixing the test_image_modifications.cpp which fails to compile? Also do we need a PR for the compile error for VS2015 in color.cpp?
20161201 20:00:52< irker804> wesnoth: Jyrki Vesterinen wesnoth:master 9047493bb973 / utils/appveyor/irc-notify.py: AppVeyor IRC notification: attempted fix for wrong build URL https://github.com/wesnoth/wesnoth/commit/9047493bb97390a784b395c6b041d82fabcb9889
20161201 20:00:54< celticminstrel> No-one is currently working on that fix AFAIK.
20161201 20:01:28< tad_carlucci> OK. I'll look at them.
20161201 20:02:01< celticminstrel> There's a compiler error in color.cpp?
20161201 20:02:11 * celticminstrel will try a MSVC 2013 build...
20161201 20:03:10< JyrkiVesterinen> It is building with VS2013 but not with VS2015.
20161201 20:04:10< tad_carlucci> 32_t needs narrowing cast to 8_t
20161201 20:07:10< celticminstrel> Ah.
20161201 20:07:21< celticminstrel> What line?
20161201 20:07:45< JyrkiVesterinen> 73
20161201 20:08:08< tad_carlucci>  ..\..\src\color.cpp(74): error C2398: Element '4': conversion f
20161201 20:08:21< celticminstrel> Okay, I'll get that one then.
20161201 20:08:42< tad_carlucci> The test is a lot of color_t vs unit32_t stuff
20161201 20:13:23-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 20:13:32-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161201 20:13:39-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 20:13:48-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161201 20:16:41-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161201 20:16:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20161201 20:17:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161201 20:17:39-!- travis-ci [~travis-ci@ec2-54-90-108-235.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 20:17:41< travis-ci> wesnoth/wesnoth#12260 (master - 12c57a7 : Charles Dang): The build failed.
20161201 20:17:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180430871
20161201 20:17:41-!- travis-ci [~travis-ci@ec2-54-90-108-235.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 20:21:34< celticminstrel> src/game_errors.cpp is empty, is it even needed?
20161201 20:23:05< gfgtdf> celticminstrel: i guess not
20161201 20:23:37< celticminstrel> I guess I'll try removing it...
20161201 20:24:33-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Ping timeout: 244 seconds]
20161201 20:25:16-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20161201 20:25:35< tad_carlucci> Wasn't it there to document the hpp?
20161201 20:25:52< tad_carlucci> I seem to recall asking the question and getting that answer a month or two ago
20161201 20:26:25< celticminstrel> It doesn't even contain Doxygen comments.
20161201 20:26:35< celticminstrel> I recall you asking something like that about another file though?
20161201 20:26:48< celticminstrel> Something like src/gui/auxiliary/iterator/iterator.cpp?
20161201 20:27:12 * tad_carlucci shrugs
20161201 20:28:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 20:30:57< celticminstrel> Should I implement missing operators for classes that have only == and/or only < ?
20161201 20:31:10< celticminstrel> (Or only the two of those)
20161201 20:31:47< tad_carlucci> PR889 should get travis happy
20161201 20:31:51< celticminstrel> (IIRC Boost has some easy way of doing that?)
20161201 20:32:36< celticminstrel> I'll merge PR889 after I push, then, since my color.hpp change should also fix MSVC 2015 and with those together everything should work.
20161201 20:32:47 * tad_carlucci smiles
20161201 20:33:19< celticminstrel> Any opinion on the operators?
20161201 20:33:26< Soliton> does wesnoth still build with sdl 2.0.2?
20161201 20:33:34< tad_carlucci> As to missing operators. IF you have == you really should have != .. similar to the < <= > >= set. 
20161201 20:33:40< Soliton> i think sdl 2.0.4 was only needed for some bugfix?
20161201 20:33:54< tad_carlucci> Soliton, Yes it builds. No you won't like how it looks on screen
20161201 20:33:58< celticminstrel> Soliton: I think it'll build, but you might get graphical glitches on some systems.
20161201 20:34:08< Soliton> i just want it to parse wml.
20161201 20:34:27< Soliton> any idea how i can disable the version check for cmake?
20161201 20:34:44< tad_carlucci> I edit the config
20161201 20:35:05< Soliton> i know nothing about cmake.
20161201 20:35:34< tad_carlucci> Not too different here. Just scan for sdl .. iirc you'll see what needs changing
20161201 20:35:39< Soliton> CMakeCache.txt?
20161201 20:36:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161201 20:37:47< Soliton> well, if someone can figure that out i can probably restore units.wesnoth.org for master.
20161201 20:38:10 * Soliton leaves.
20161201 20:38:17< tad_carlucci> I think that's where the version check is. I do trial and error
20161201 20:42:01-!- mjs-de [~mjs-de@x4e312d92.dyn.telefonica.de] has joined #wesnoth-dev
20161201 20:44:50< Aginor> CmakeLists.txt contains the version check
20161201 20:45:14< Aginor> just search for 2.0.4 and replace it with 2.0.2
20161201 20:45:40< tad_carlucci> JyrkiVesterinen, appveyor links work well, now.
20161201 20:46:26< JyrkiVesterinen> Great. :) Do you think I can redirect the notifications to this channel now?
20161201 20:47:55< tad_carlucci> I'll take down my projects so I don't spam every push and it looks good to me if you're happy with the schedule
20161201 20:50:52< irker804> wesnoth: Jyrki Vesterinen wesnoth:master 2aded543487c / .appveyor.vs2013.yml .appveyor.vs2015.yml: Redirect AppVeyor IRC notifications to #wesnoth-dev https://github.com/wesnoth/wesnoth/commit/2aded543487c56bbc4501f1de4fc08d8fce8f846
20161201 20:51:00< JyrkiVesterinen> It's done.
20161201 20:51:20< tad_carlucci> And I'm cleared off so we're live. YEAH!
20161201 20:53:33-!- Shiki [~Shiki@141.57.60.11] has quit [Quit: Verlassend]
20161201 20:59:00-!- Shiki [~Shiki@141.57.60.11] has joined #wesnoth-dev
20161201 20:59:24-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161201 20:59:46-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 21:04:43-!- JyrkiVesterinen [~JyrkiVest@89-166-118-169.bb.dnainternet.fi] has quit [Quit: Going to bed]
20161201 21:05:41-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161201 21:06:05-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 21:06:49-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161201 21:10:18-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 246 seconds]
20161201 21:10:18-!- wedge010 is now known as wedge009
20161201 21:18:04< irker804> wesnoth: Celtic Minstrel wesnoth:master 9cbd31dba7b6 / src/color.hpp: color_t fixup: constant had wrong type https://github.com/wesnoth/wesnoth/commit/9cbd31dba7b6e53fccb23414ad5629f30a3444ef
20161201 21:18:06< irker804> wesnoth: Celtic Minstrel wesnoth:master c2ed9c5c1982 / / (10 files in 5 dirs): MSVC project file cleanup https://github.com/wesnoth/wesnoth/commit/c2ed9c5c1982a3bf6f25fd4aa4453e9607207506
20161201 21:18:28< irker804> wesnoth: Gregory A Lundberg wesnoth:master 52ec04b02b8b / src/tests/test_image_modifications.cpp: Fix bug: Upgrade tests/test_image_modifications.cpp for color_t (#889) https://github.com/wesnoth/wesnoth/commit/52ec04b02b8b649caa70d3f14d5241e1052074b2
20161201 21:23:23-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161201 21:23:24-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161201 21:28:12-!- atarocch [~atarocch@host-78-65-187-41.homerun.telia.com] has quit [Ping timeout: 256 seconds]
20161201 21:33:20-!- atarocch [~atarocch@host-78-65-187-41.homerun.telia.com] has joined #wesnoth-dev
20161201 21:54:18-!- mjs-de [~mjs-de@x4e312d92.dyn.telefonica.de] has quit [Remote host closed the connection]
20161201 21:55:16< gfgtdf> tad_carlucci: did you see https://gna.org/bugs/?25348 ?
20161201 22:02:35< tad_carlucci> No, I'd not seen it. I imagine somehow it's running the die event on a unit which does not exist any longer.
20161201 22:07:54< tad_carlucci> gfgtdf, Is there a way to reproduce it? I'm guessing the 'last breath' deleted the unit and a i->valid() guard will solve it.
20161201 22:08:37< vultraz> tad_carlucci: besides appvoyer, do you have any updates on the whole smart list debacle?
20161201 22:09:10< gfgtdf> tad_carlucci:  dont know more thn the bugreport, i just pinged you becsue afaik you made the mentioned  commit (c66325856b73d)
20161201 22:11:26< tad_carlucci> gfgtdf, I'll take a look at it in a while. System too busy building VS2015/Debug right now.
20161201 22:11:39< gfgtdf> tad_carlucci: ok thx
20161201 22:11:51< Shiki> tad_carlucci, there is. you can download and copy War of the Dragon from 1.12, skip to scenario 6 and kill your leader
20161201 22:12:07< tad_carlucci> vultraz, I've not looked at it in a while. The problem is deciding where to draw the line.
20161201 22:12:20< tad_carlucci> Shiki, You the author or just playing?
20161201 22:12:46< Shiki> the author is Velensk, but i started fixing bugs in it recently
20161201 22:13:31< tad_carlucci> Shiki, Do you know if the 'last breath' at the at point fiddles with the units, killing the one which is dieing?
20161201 22:14:18< Shiki> it kills all units of you side then
20161201 22:14:38< celticminstrel> vultraz: Please try this: http://celmin.pwcsite.com/wesnoth/tests.cbp
20161201 22:14:41< tad_carlucci> Shiki, My thinking is to wrap that i->sethitpoints in an i->valid() .. if you can test that, and it works, you'll probaby get to it befire my system de-lags.
20161201 22:15:02< vultraz> This page contains the following errors:
20161201 22:15:03< vultraz> error on line 1063 at column 3: Unescaped '<' not allowed in attributes values
20161201 22:15:05< vultraz> Below is a rendering of the page up to the first error.
20161201 22:15:06< vultraz> celticminstrel: ?
20161201 22:15:50< celticminstrel> vultraz: You keep breaking unit tests because you can't build them.
20161201 22:15:57< celticminstrel> So try that and see if you can build them.
20161201 22:16:12< vultraz> ...
20161201 22:16:34< vultraz> I literally just said what I see when I look at that page
20161201 22:16:44< celticminstrel> Ah.
20161201 22:16:48< celticminstrel> Sorry.
20161201 22:17:06< celticminstrel> Probably incorrect MIEM type.
20161201 22:17:09< celticminstrel> ^MIME
20161201 22:17:14< tad_carlucci> celticminstrel, Arg: "Cannot open source file src/game_errors.cpp .. Did I forget to update the VC14 project here?
20161201 22:17:26< celticminstrel> vultraz: You can likely choose Save As though.
20161201 22:18:30< tad_carlucci> View page source and it's just fine. I'ts not HTML is all
20161201 22:18:43< celticminstrel> Yeah.
20161201 22:18:47< celticminstrel> That'd work too.
20161201 22:18:52< celticminstrel> It's XML, not HTML.
20161201 22:19:00< gfgtdf> its not xml at all*
20161201 22:19:07< celticminstrel> Isn't it?
20161201 22:19:10< celticminstrel> Sure looks like it though.
20161201 22:19:26< tad_carlucci> <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
20161201 22:19:26< tad_carlucci> <CodeBlocks_project_file>
20161201 22:19:27< gfgtdf> celticminstrel: did you write it by hand? thre are some " missing
20161201 22:19:37< tad_carlucci> Now that could be
20161201 22:19:46< gfgtdf> at about 7/8 of that file
20161201 22:20:02< celticminstrel> Uhh... are there? I'll fix that, give me a few minutes.
20161201 22:22:39-!- 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.]
20161201 22:23:26< celticminstrel> vultraz: Try again, same URL.
20161201 22:23:56< celticminstrel> The funny thing is that, even though I did write it by hand, CodeBlocks didn't complain when I tried to open it (or if it did I missed it).
20161201 22:24:57< gfgtdf> celticminstrel: still comt " missing, see the /src/tests/gui/fire_event.cpp line
20161201 22:25:32< celticminstrel> Updated again.
20161201 22:25:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 246 seconds]
20161201 22:27:14< gfgtdf> ok firefox doesnt complain anymore
20161201 22:31:34-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161201 22:43:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161201 22:55:20-!- Kwandulin [~Miranda@p200300760F6EBFA9EC892BCF51037504.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20161201 23:00:03-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161201 23:10:53< vultraz> .objs-release\src\color_range.o:color_range.cpp|| undefined reference to `color_t::to_hex_string[abi:cxx11]() const'|
20161201 23:10:56< vultraz> aw come on
20161201 23:11:05< celticminstrel> ?
20161201 23:11:25< vultraz> im getting a linker error here
20161201 23:11:54< celticminstrel> Okay?
20161201 23:12:10< vultraz> not sure why
20161201 23:13:51< vultraz> ...and now it went away
20161201 23:13:54< vultraz> go figure
20161201 23:14:31< vultraz> *includes #color.hpp in cpp file. error goes away. removes said include. error still gone*
20161201 23:14:34< vultraz> *rolls eyes*
20161201 23:14:45< vultraz> anyway, your site is down
20161201 23:14:50< vultraz> no dns address
20161201 23:14:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161201 23:16:03< celticminstrel> vultraz: http://23.226.229.74/wesnoth/tests.cbp (though the DNS is still working for me)
20161201 23:16:39< celticminstrel> I don't actually control that domain (someone I know let me use the subdomain under it).
20161201 23:19:48-!- Appleman1234 [~Appleman1@KD106161214157.au-net.ne.jp] has joined #wesnoth-dev
20161201 23:25:07-!- Appleman1234 [~Appleman1@KD106161214157.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20161201 23:25:08-!- Appleman1234_ [~Appleman1@106.161.199.206] has joined #wesnoth-dev
20161201 23:25:35-!- Appleman1234_ is now known as Appleman1234
20161201 23:26:10< Shiki> tad_carlucci, worked
20161201 23:26:13-!- Shiki [~Shiki@141.57.60.11] has quit [Quit: Verlassend]
20161201 23:49:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161201 23:49:32< irker804> wesnoth: Charles Dang wesnoth:master 32f6ef3beaa1 / src/editor/ (13 files in 4 dirs): Editor: use src/-relative include paths https://github.com/wesnoth/wesnoth/commit/32f6ef3beaa1af2cb9a726764f9580c775e8e2e4
20161201 23:53:18-!- travis-ci [~travis-ci@ec2-54-196-7-154.compute-1.amazonaws.com] has joined #wesnoth-dev
20161201 23:53:19< travis-ci> wesnoth/wesnoth#12262 (master - 9047493 : Jyrki Vesterinen): The build failed.
20161201 23:53:20< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/180507909
20161201 23:53:20-!- travis-ci [~travis-ci@ec2-54-196-7-154.compute-1.amazonaws.com] has left #wesnoth-dev []
20161201 23:57:43-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
--- Log closed Fri Dec 02 00:00:16 2016