--- Log opened Fri Apr 01 00:00:54 2016
20160401 00:05:31-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160401 00:08:20-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160401 00:08:21-!- wedge010 is now known as wedge009
20160401 00:10:37-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160401 00:13:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 00:14:37< mattsc> celticminstrel: Will do.  Some time.
20160401 00:18:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 00:20:43 * vultraz considers how to replicate the nice background effect our buttons have
20160401 00:21:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 00:21:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 00:25:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 00:27:56 * celticminstrel fiddles with the loadscreen.
20160401 00:28:12 * celticminstrel also considers how to test gradients if and when I start implementing them.
20160401 00:28:51< vultraz> do you really think the rounded corners are necessary
20160401 00:29:04< celticminstrel> I really think it looks better with rounded corners.
20160401 00:29:19< celticminstrel> Fortunately, rounded corners are not actually very difficult.
20160401 00:30:04< celticminstrel> You know, maybe I should add [arc] instead of [round_rectangle]... though the latter would be a bit more convenient...
20160401 00:30:16< celticminstrel> Hmm, what did I break...
20160401 00:30:22< celticminstrel> It was working a moment ago...
20160401 00:31:07< celticminstrel> ...okay, must've been a fluke...
20160401 00:35:31< vultraz> https://drive.google.com/file/d/0B-mR9s8FduLLYjl2ZEl1ZFBYVzA/view?usp=sharing
20160401 00:35:34< vultraz> final version
20160401 00:35:56< vultraz> I honestly can't really tell the difference between this and the old ones unless you look really closely
20160401 00:35:59< celticminstrel> How can it be final if you don't have rounded rects or gradients yet? :|
20160401 00:37:23< celticminstrel> The rounded corners look bad, and I think zookeeper is right that the gradient makes it look better.
20160401 00:37:37< celticminstrel> I'm looking at them side-by-side right now, and the original definitely looks better.
20160401 00:37:57< vultraz> "final" barring any yet-unimplemented features
20160401 00:38:03< celticminstrel> Fair enough, I suppose.
20160401 00:38:35< celticminstrel> I don't think I like the increased font size.
20160401 00:38:46< celticminstrel> I suppose I could get used to it though.
20160401 00:39:12< celticminstrel> I wonder if it would look better in bold.
20160401 00:39:27< celticminstrel> ...it's pretty big already though...
20160401 00:39:28< vultraz> I did follow the old design pretty faithfully. I could come up with a new design, if I wanted..
20160401 00:39:42< celticminstrel> Old design of what?
20160401 00:39:47< vultraz> the buttons
20160401 00:39:57< celticminstrel> I was complaining about the font.
20160401 00:40:03< vultraz> it's related
20160401 00:40:13< vultraz> see, the old button spends a lot of space on borders
20160401 00:40:28< vultraz> so once you have the 'center' part for text, it looks a bit cramped
20160401 00:40:34< celticminstrel> The loadscreen animation doesn't even get a chance to finish now...
20160401 00:40:46< celticminstrel> Is that because time is wasted fetching translatable strings...?
20160401 00:40:54< vultraz> no, it's just fast
20160401 00:41:36< celticminstrel> And yet, with just gfgtdf's changes, the animation does have time to finish... at least twice, I think.
20160401 00:41:47< celticminstrel> Well, it's not really important though.
20160401 00:41:51< vultraz> not for me
20160401 00:41:58< celticminstrel> I have a slow computer.
20160401 00:42:01< celticminstrel> Probably.
20160401 00:42:05< celticminstrel> Something like that.
20160401 00:42:38< celticminstrel> Any thoughts about changing the loadscreen animation from . to * ?
20160401 00:42:53< vultraz> why?
20160401 00:42:56< celticminstrel> No reason.
20160401 00:43:06< vultraz> dislike
20160401 00:43:08< celticminstrel> Just a random thought.
20160401 00:43:10< celticminstrel> Okay.
20160401 00:44:33< celticminstrel> I've set the loadscreen to use the exact same translatable strings as the old loadscreen.
20160401 00:44:42< celticminstrel> So if they were already translated, they won't even need updating.
20160401 00:44:51< celticminstrel> Though some might be better tweaked, but I'll leave that to you.
20160401 00:46:04< celticminstrel> The loadscreen does take longer when actually starting a game though.
20160401 00:46:28< celticminstrel> Do we need the "starting game" stage? I did see it show up for a couple of seconds...
20160401 00:47:02< vultraz> give me a list of all stages
20160401 00:47:18< celticminstrel> You can't wait until I commit it?
20160401 00:47:29< celticminstrel> There's currently a list at the top of loadscreen.cpp.
20160401 00:49:35< vultraz> there is?
20160401 00:49:46< celticminstrel> In my local copy, yes.
20160401 00:50:00< vultraz> I see not
20160401 00:51:00< celticminstrel> I haven't committed it yet.
20160401 00:52:33< celticminstrel> I'll leave the "starting game" stage for now. I've removed "init gui" and "titlescreen".
20160401 00:52:59< vultraz> good, good
20160401 00:53:13< vultraz> celticminstrel: https://drive.google.com/file/d/0B-mR9s8FduLLQlN2TUhhVnJYelU/view?usp=sharing
20160401 00:54:01< gfgtdf> is anyone else currently doing changes to config.hpp ?
20160401 00:54:16< vultraz> no
20160401 00:54:18< vultraz> t me
20160401 00:54:21< celticminstrel> No. I had thought about adding initializer_list support to it, but I haven't gotten to that.
20160401 00:55:16< celticminstrel> (Though config_of is probably a little more convenient than an initializer_list in the general case.)
20160401 00:55:59< celticminstrel> For some reason the logo disappears during the "starting game" stage.
20160401 00:56:18< vultraz> indeed
20160401 00:56:31< celticminstrel> That was already the case? Alright then.
20160401 00:57:27< celticminstrel> I have a cache error.
20160401 00:57:27< vultraz> looking at these in comparison, you're right
20160401 00:57:30< vultraz> gradient effect needed
20160401 00:57:40< vultraz> but I still need to pick a design..
20160401 00:58:15-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160401 00:59:20< vultraz> bottom is like middle, but cleaner..
20160401 00:59:56< vultraz> yeah I think I'll go with bottom
20160401 01:02:47-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has joined #wesnoth-dev
20160401 01:03:18< vultraz> looks MUCH better with gradient, yes...
20160401 01:03:47< celticminstrel> I didn't see different designes...
20160401 01:04:07< celticminstrel> Can you tell what kind of gradient effect is used?
20160401 01:04:16< celticminstrel> Is it linear, or circular, or what?
20160401 01:04:22< celticminstrel> ^designs
20160401 01:04:50< vultraz> linear
20160401 01:05:18< vultraz> celticminstrel: I updated the image with a drawn gradient for the bottom design
20160401 01:05:49< vultraz> top-right (light) to bottom-left (dark) linear gradient
20160401 01:06:09< celticminstrel> gfgtdf: Do you know any reason why game_state::bind needs the whiteboard manager? It doesn't do anything with it.
20160401 01:06:34< vultraz> so yeah, I'll hold off on this until we get graidents
20160401 01:06:45< celticminstrel> I'll probably work on that next.
20160401 01:06:51< celticminstrel> Either that or round rectangles.
20160401 01:06:59< gfgtdf> celticminstrel: hmm no i don't
20160401 01:07:08< vultraz> celticminstrel: gradients first, please
20160401 01:13:47-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160401 01:15:49< gfgtdf> vultraz: you know that there are still some c++11 include guards left: https://github.com/wesnoth/wesnoth/search?utf8=%E2%9C%93&q=HAVE_CXX11 ?
20160401 01:16:39< ancestral> vultraz: Your button comparison, I think I like the original better, but only because it stands out more. Perhaps if the other versions had stronger gold colors then I could be persuaded
20160401 01:17:03< ancestral> Also, I think a little more button padding might be helpful with the new font
20160401 01:17:22< ancestral> i.e. slightly larger buttons
20160401 01:18:12< irker509> wesnoth: gfgtdf wesnoth:master b6282d866293 / src/ (config.cpp config.hpp): use c++11 heterogeneous map lookups in config if possible. https://github.com/wesnoth/wesnoth/commit/b6282d866293c615e2fa4ebff06b4600da3ac663
20160401 01:20:17< irker509> wesnoth: gfgtdf wesnoth:master bc20a3d7d9d5 / src/ (config.cpp config.hpp): remove a c++11 #ifdef https://github.com/wesnoth/wesnoth/commit/bc20a3d7d9d543ce0cc9b630ab8695e5b927452c
20160401 01:21:24< celticminstrel> We should decide where to move "Cores" to.
20160401 01:22:40< vultraz> we should
20160401 01:23:03< gfgtdf> i also agree
20160401 01:25:05< vultraz> i thought i removed all include guards..
20160401 01:25:21< vultraz> will fix
20160401 01:27:16< irker509> wesnoth: Charles Dang wesnoth:master 51957589ed9a / src/ (gui/auxiliary/filter.hpp units/map.hpp variable.hpp): Removed some C++11 include guards I missed https://github.com/wesnoth/wesnoth/commit/51957589ed9a5ae18484301b140032f4fa2d1332
20160401 01:27:42< ShikadiLord> Wow, the load screen looks very vultraz now.
20160401 01:27:52< ShikadiLord> all lowercase and stuff
20160401 01:28:12< celticminstrel> XD
20160401 01:28:22< celticminstrel> Not for long.
20160401 01:28:33< ShikadiLord> Good, good.
20160401 01:29:31< ShikadiLord> I heard you are using C++11 in master now?
20160401 01:29:36< celticminstrel> Yes.
20160401 01:30:22-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160401 01:30:25< vultraz> and I'm minimalizing ALL the gui things.
20160401 01:30:54< vultraz> soon we'll have procedural buttons
20160401 01:30:56-!- gfgtdf_ [~chatzilla@x50ab6f7b.dyn.telefonica.de] has joined #wesnoth-dev
20160401 01:30:57< ShikadiLord> So this is it then.
20160401 01:31:02< ShikadiLord> The year Wesnoth dies, I mean.
20160401 01:31:10< vultraz> then you can replicate our buttons in css
20160401 01:31:34< ShikadiLord> I mean by the sounds of it you are pulling a Microsoft and firing all the UI designers and replacing them with the coders' children.
20160401 01:32:37< ShikadiLord> No amount of revolutionary framework improvements is ever going to paper over all the bad UI design that's going on there, so I advise you don't take them as an example to follow.
20160401 01:33:01-!- gfgtdf [~chatzilla@f054149045.adsl.alicedsl.de] has quit [Ping timeout: 268 seconds]
20160401 01:33:05-!- gfgtdf_ is now known as gfgtdf
20160401 01:33:48< ShikadiLord> Unless you are really desperate to make Wesnoth trendy and popular, in which case you might as well start by removing all the mainline portraits and replacing them with mass-produced anime-style equivalents.
20160401 01:33:55< fendrin> :-)
20160401 01:34:00< celticminstrel> XD
20160401 01:34:37< celticminstrel> I wonder if there's any point in keeping loading-screen stages that don't show up...
20160401 01:35:23< vultraz> "Konrad-senpai wants wants Lisar-chan to notice him!"
20160401 01:35:53< celticminstrel> Pretty sure that implies another character who doesn't exist.
20160401 01:36:40< celticminstrel> I think it doesn't hurt to have loading-screen stages that don't show up.
20160401 01:37:04< celticminstrel> Maybe they'll show up very occasionally in special circumstances.
20160401 01:37:59< fendrin> Controlled by random number generator and the constellation of the stars.
20160401 01:40:27< irker509> wesnoth: Celtic Minstrel wesnoth:master 1c5f6024fd22 / src/ (game_config_manager.cpp game_launcher.cpp wesnoth.cpp): Reduce needlessly large closures https://github.com/wesnoth/wesnoth/commit/1c5f6024fd2274611b994ef51c476b251756eb2b
20160401 01:40:29< irker509> wesnoth: Celtic Minstrel wesnoth:master a5cd2c7f4ad4 / src/ (4 files in 2 dirs): Restore loadscreen translatable stage messages https://github.com/wesnoth/wesnoth/commit/a5cd2c7f4ad43f21a6e94c8f7fd634bea9d82a7b
20160401 01:40:31< irker509> wesnoth: Celtic Minstrel wesnoth:master 1368a05ee996 / src/ (game_launcher.cpp play_controller.cpp wesnoth.cpp): Correct indentation https://github.com/wesnoth/wesnoth/commit/1368a05ee996ba9404b97bac1236c9bf36b1bb2d
20160401 01:40:33< irker509> wesnoth: Celtic Minstrel wesnoth:master d9eab21bd012 / src/ (game_state.cpp game_state.hpp play_controller.cpp): Remove redundant gamestate::bind() https://github.com/wesnoth/wesnoth/commit/d9eab21bd0123c3c2271a6f3f27bfe8318ed36cf
20160401 01:40:35< irker509> wesnoth: Celtic Minstrel wesnoth:master e35e46ec2e51 / src/xBRZ/xbrz.cpp: Enable commented C++11 xBRZ code https://github.com/wesnoth/wesnoth/commit/e35e46ec2e517f0f2be1fe2c788d05b807f58863
20160401 01:41:03< celticminstrel> I think I had other things to do with the loadscreen, but I can't remember what they were, so they'll have to wait.
20160401 01:41:22< ShikadiLord> I'm legitimately curious how range-for compares to BOOST_FOREACH in terms of both emitted code (assembly) and compiler overhead. I assume it's much better in terms of the latter since the compiler knows the magic underneath the loop construct and doesn't need a gazillion template metaprogramming thingamabobs to help it generate the required C++.
20160401 01:41:45< ShikadiLord> And I see BOOST_FOREACH is still used a lot.
20160401 01:42:01< celticminstrel> It'll be better for debugging since there won't be a gazillion private BOOST_FOREACH variables.
20160401 01:43:16< ShikadiLord> You mean live debugging? Never had the misfortune of having to inspect a BOOST_FOREACH loop, I think.
20160401 01:43:49< ShikadiLord> Compile-time errors, though...
20160401 01:43:56< vultraz> indeed
20160401 01:44:00< vultraz> so annoying
20160401 01:44:15< vultraz> I think range-for is the next thing he's working on
20160401 01:44:23< vultraz> or next cleanup thing..
20160401 01:44:25< vultraz> or something
20160401 01:45:16< celticminstrel> I was indeed going to do some range-for stuff.
20160401 01:45:19< celticminstrel> In two stages.
20160401 01:45:19< ShikadiLord> Also, have you decided on a policy for `auto`?
20160401 01:45:29< celticminstrel> Like, a code-style policy?
20160401 01:45:32< gfgtdf> celticminstrel: hmm you did see the 'Note we cannot use std::strings here unless we we explicitly use mutexes' comment right ?
20160401 01:45:33< ShikadiLord> Yes.
20160401 01:45:52< celticminstrel> gfgtdf: Yes, what about it?
20160401 01:46:14< vultraz> auto is fun
20160401 01:46:22< gfgtdf> celticminstrel: you removed it and changes teh type to someting non trivial
20160401 01:46:27< ShikadiLord> It's "fun" and also easy to abuse.
20160401 01:46:50< celticminstrel> Yes, it's an iterator.
20160401 01:46:58< vultraz> celticminstrel: when you tackle range-for, will you also remove FOREACH
20160401 01:47:04< celticminstrel> vultraz: That's stage 1.
20160401 01:47:10< vultraz> ah
20160401 01:47:11< vultraz> good, good
20160401 01:47:37< gfgtdf> celticminstrel: y but the comment said exactly not to change it something nontrivial unless you know its internal meorylayout very well
20160401 01:48:03< celticminstrel> Perhaps you could explain the logic behind this, because I don't understand what you're saying the issue is.
20160401 01:48:57< gfgtdf> celticminstrel: the variable 'current_stage_' is acesses by both threads simultaniously
20160401 01:49:10< gfgtdf> celticminstrel: and you need to make sure this doesn't cause bugs
20160401 01:49:20< celticminstrel> Hmm... you're right, now that I think of it...
20160401 01:49:55< celticminstrel> I should also mark it volatile then, just to be safe (it doesn't do much, but still).
20160401 01:50:18< celticminstrel> So, what kinds of bugs would it cause?
20160401 01:50:36< celticminstrel> Let's assume for now that it just contains a pointer.
20160401 01:50:54 * celticminstrel isn't sure if that's the case, though it would make sense.
20160401 01:50:58< gfgtdf> celticminstrel: the previous code was based one the assumtion that reading  a void*/int value happens atomic which is afaik the case on th eprocessors i know..,
20160401 01:52:14< gfgtdf> celticminstrel: so if its not a 16-byte structor, it could happen that thread 1 writes the first part of the data, then thread 2reads te full data, and then thread 1 writed the other part of the data.
20160401 01:53:33< gfgtdf> celticminstrel: worse things will happen if current_stage_ was a std::strign or similar which has to mange it own buffer.
20160401 01:54:43< gfgtdf> celticminstrel: i actualyl wonder why we need the map in the first place instead of always using the 'translatble' string (e.g "Building terrain rules")
20160401 01:55:35< gfgtdf> celticminstrel: about 1c5f6024fd2274611b994ef51c476b251756eb2b
20160401 01:56:02< gfgtdf> celticminstrel: i actually assume that the compiler woudl automatically unly use thse variables that are needed and not 'everythign avaialbe in current scope'
20160401 02:00:49-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 02:00:50< travis-ci> wesnoth/wesnoth#9149 (master - bc20a3d : gfgtdf): The build has errored.
20160401 02:00:50< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119966178
20160401 02:00:50-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 02:10:14< gfgtdf> s/its not a 16-byte structor/its now a 16-byte strucure
20160401 02:10:28< celticminstrel> gfgtdf: Yeah, the compiler might do that, not sure.
20160401 02:11:15< celticminstrel> gfgtdf: However, I do think using [=] was not a good idea.
20160401 02:12:45< celticminstrel> I can't tell what the size of the const_iterator is since it's hidden behind lots of template trickery. I suspect it's just a pointer, but I can't prove that.
20160401 02:13:40< celticminstrel> Should I add a mutex? That might slow it down a bit though...
20160401 02:14:28< celticminstrel> Maybe it would work to store a pointer to pair instead?
20160401 02:14:51< gfgtdf> celticminstrel: hmm i still don
20160401 02:15:21< celticminstrel> Or, I could store the string in current_stage_ and look it up in timer_callback instead of in progress.
20160401 02:15:58< gfgtdf> 't see why we need the list on the first place instead of just writing gui2::tloadscreen::progress(_N("Building terrain rules")); (using the translatable string directly )
20160401 02:16:14< celticminstrel> We could do that, of course.
20160401 02:16:32< celticminstrel> Doing it this way ensures they're all in the same textdomain, though.
20160401 02:16:48< celticminstrel> And also puts them all in one place.
20160401 02:16:57< celticminstrel> (You'd use _, not N_, though.)
20160401 02:17:11< celticminstrel> (N_ doesn't perform a lookup, merely marks it for xgettext.)
20160401 02:17:43< gfgtdf> celticminstrel: hmm yes i didnt think of the textdomain issue, i dont think having rhem all in one placce is an advantage though.
20160401 02:18:01< celticminstrel> So, should I do one of the things I suggested?
20160401 02:18:33< gfgtdf> celticminstrel: no i intentional plan was to use N_ and do the translations in timer_callback liek its currently done, but yea the textdomains are an issue
20160401 02:18:40< celticminstrel> Ah.
20160401 02:18:58< gfgtdf> celticminstrel: in any case adding std::atomic to that variable is a good ting i think
20160401 02:19:06< celticminstrel> How does that work?
20160401 02:19:13< celticminstrel> std::atomic<blah>?
20160401 02:19:40-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 02:19:41< travis-ci> wesnoth/wesnoth#9148 (master - b6282d8 : gfgtdf): The build has errored.
20160401 02:19:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119965975
20160401 02:19:41-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 02:19:52< gfgtdf> celticminstrel: y but it might only work for simple types
20160401 02:20:10< celticminstrel> const_iterator is a fairly simple type. (No idea if it's simple enough.)
20160401 02:20:15< celticminstrel> I'll look it up.
20160401 02:23:12< celticminstrel> gfgtdf: Why GCC 5 and clang 3.4?
20160401 02:23:56< gfgtdf> celticminstrel: andother way woudl be to use make_enumand ints similar to how its done for the female unittpye alignment, so that people woudl have to write gui2::tloadscreen::progress(gui2::tloadscreen::stage::building_terrain_rules)
20160401 02:24:24< gfgtdf> celticminstrel: becasue thats the versions that surrpt that feature (heterogenous lookups)accoring to a page on the inernet
20160401 02:24:25< celticminstrel> I thought about that, but it somehow felt inflexible. Then again, I suppose it's not significantly worse than the current way...
20160401 02:24:40< celticminstrel> I see...
20160401 02:26:30< gfgtdf> celticminstrel: note that heterogenous lookups don'r require c++11 core feautes afaik, so it shodulbe possible to write cusom map/ste classes that support it even without c++11
20160401 02:26:30-!- travis-ci [~travis-ci@ec2-54-92-147-78.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 02:26:31< travis-ci> wesnoth/wesnoth#9150 (master - 5195758 : Charles Dang): The build has errored.
20160401 02:26:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119966904
20160401 02:26:31-!- travis-ci [~travis-ci@ec2-54-92-147-78.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 02:28:57< celticminstrel> Well, that's interesting. My clang claims to be version 4.2.
20160401 02:29:57< gfgtdf> celticminstrel: most recent version is 3.7 arroding to wkipedia
20160401 02:30:03< celticminstrel> Yeah, so uh...
20160401 02:30:10< celticminstrel> Not good.
20160401 02:30:24< celticminstrel> mattsc: If you're around, could you try something quickly?
20160401 02:30:40< celticminstrel> Output of clang -dM -E -x c /dev/null | grep clang
20160401 02:31:04< celticminstrel> Specifically the major/minor.
20160401 02:33:05< celticminstrel> I actually have clang 3.3, 3.4, 3.7, and 3.8 installed, apparently. The latter doesn't work though.
20160401 02:35:11< celticminstrel> Also mattsc: clang -dM -E -x c /dev/null | grep apple_build
20160401 02:35:41-!- gfgtdf [~chatzilla@x50ab6f7b.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160315153207]]
20160401 02:37:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 02:38:54< mattsc> celticminstrel: http://pastebin.com/X0fKSvrs
20160401 02:39:07< celticminstrel> Thanks.
20160401 02:39:17< celticminstrel> Wha.... 7.3? o.o
20160401 02:39:32< mattsc> apparently
20160401 02:39:34< celticminstrel> But at least it does still define __apple_build_version__ so it can be distinguished.
20160401 02:40:03< celticminstrel> Does clang --version have something about "based on clang 3.2"?
20160401 02:41:33< mattsc> nope
20160401 02:41:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160401 02:41:55< mattsc> Apple LLVM version 7.3.0 (clang-703.0.29)      Target: x86_64-apple-darwin15.4.0
20160401 02:44:07< celticminstrel> Hmm, Google suggests that Apple clang 5.1 is about equivalent to official clang 3.4.
20160401 02:44:26< celticminstrel> The "based on" string stopped appering in 7.0.
20160401 02:44:52< celticminstrel> Which also corresponds with XCode 7... I think they're using XCode version numbers.
20160401 02:45:16< celticminstrel> Yeah, the clang version is always the same major revision as the XCode version.
20160401 02:50:20-!- travis-ci [~travis-ci@ec2-54-92-147-78.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 02:50:21< travis-ci> wesnoth/wesnoth#9151 (master - e35e46e : Celtic Minstrel): The build has errored.
20160401 02:50:21< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119968321
20160401 02:50:21-!- travis-ci [~travis-ci@ec2-54-92-147-78.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 02:53:13< celticminstrel> I've got that compiler detection set up for clang and GCC now.
20160401 03:13:25< vultraz> celticminstrel: for some reason, the display of strings on the loadscreen doesn't seem consistent.. sometimes it ends with "initializing fonts for the current language", sometimes it's "searching for installed addons"
20160401 03:13:52< vultraz> and it seems to alternate between loads
20160401 03:14:11< celticminstrel> That could be because of what gfgtdf brought up.
20160401 03:14:31< celticminstrel> I've just finished something that might fix it.
20160401 03:14:57< celticminstrel> Alternatively, it could be simply because a stage finishes so fast that it doesn't have a chance to appear.
20160401 03:23:00< Aginor> gfgtdf: looks ok, I take more objection to the hacks you've added in the event handlers to stop event processing if the loading screen is showing for certain components
20160401 03:28:08< mattsc> Ooo, segfault when starting HttT.
20160401 03:28:13< mattsc> But only the first time.
20160401 03:28:51< celticminstrel> Did you catch where the segfault occurs?
20160401 03:29:30< mattsc> No.  It was while the loading screen was up, but that’s all I know.
20160401 03:29:37-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160401 03:29:54< irker509> wesnoth: mattsc wesnoth:master 1cc371199692 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Xcode project: ignore inconsistent-missing-override warning https://github.com/wesnoth/wesnoth/commit/1cc3711996923636e5e979b00dbd9f7e5dbd24d8
20160401 03:30:50< mattsc> I cannot reproduce it any more now.
20160401 03:30:53 * celticminstrel likes that clang has a warning flag to suppress warnings about unknown warning flags.
20160401 03:31:27< celticminstrel> I would hazard a guess that it's somehow related to the threaded loading screen.
20160401 03:35:08< celticminstrel> mattsc: Does your log have a message about corrupted cache?
20160401 03:37:06< mattsc> Uh, which log?  stderr?
20160401 03:37:22< celticminstrel> Whatever log the log messages normally appear in.
20160401 03:37:39< celticminstrel> If you're running from XCode it would be the run log.
20160401 03:38:00< mattsc> I’m running from terminal so they appear there.
20160401 03:38:04< celticminstrel> (Or it might show up as debug log.)
20160401 03:38:05< celticminstrel> Ah.
20160401 03:38:13< celticminstrel> So did you see any message like that?
20160401 03:38:30< mattsc> No, it’s complaining about a missing image, and the next and only thing it says is “Segmentation fault: 11"
20160401 03:38:37< celticminstrel> I see.
20160401 03:38:43< celticminstrel> What missing image?
20160401 03:38:51< mattsc> And the missing (transparent) image message also shows up when it worked, so that’s not it.
20160401 03:39:03< celticminstrel> Oh, I thought you meant like a dyld error.
20160401 03:39:09< mattsc> transparent goblin spearman portrait
20160401 03:39:23< mattsc> No, I mean a png file  :)
20160401 03:39:25< celticminstrel> Yeah, I assume that's unrelated.
20160401 03:40:01< mattsc> No, sorry, there’s no indication at all as to what went wrong.
20160401 03:40:30< mattsc> And I’ve tried a half dozen more times with the same and different campaigns and test scenarios and it’s always worked since that first time.
20160401 03:43:49< mattsc> Ah, managed to reproduce it.
20160401 03:44:08< mattsc> If I start two instances of Wesnoth from the CL, I can get one of them to segfault.
20160401 03:44:23-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160401 03:45:46-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160401 03:46:05< mattsc> Hmm, but not consistently either.
20160401 03:46:41< celticminstrel> This inconsistency is why I suspect the threading is related.
20160401 03:46:52< celticminstrel> Does it always happen during the loadscreen, BTW?
20160401 03:46:54< Aginor> it sounds like a classic threading issue
20160401 03:46:58< Aginor> a race condition
20160401 03:47:01< celticminstrel> Yeah.
20160401 03:47:11< celticminstrel> Oh, I should push this and see if it helps.
20160401 03:47:17< Aginor> how big is the performance gain?
20160401 03:48:13< mattsc> Yes, always during the loadscreen.
20160401 03:48:22< celticminstrel> I think the goal wasn't performance but rather responsiveness.
20160401 03:48:41< mattsc> I’ve gotten it to segfault 3 times now, but that’s out of at least 20 attempts.
20160401 03:48:43< celticminstrel> So that you can quit it while it's loading.
20160401 03:49:27< vultraz> I wonder if it's worth using threading for any other parts of the code
20160401 03:52:19 * ShikadiLord blinks.
20160401 03:55:08< mattsc> Okay, found a way to reproduce it: hit any key on the keyboad while the loadscreen is up.
20160401 03:55:29< mattsc> Well, I did not confirmed that any key will do, but I’ve tried several
20160401 03:55:38< vultraz> cannot reproduce
20160401 03:55:46< celticminstrel> That's... actually potentially quite helpful.
20160401 03:55:52< celticminstrel> I'll see if I can reproduce it from that.
20160401 03:56:10 * Aginor leans back
20160401 03:56:14< vultraz> WAIT
20160401 03:56:16< vultraz> I can
20160401 03:56:30< vultraz> specifically, Esc
20160401 03:56:34< vultraz> celticminstrel, mattsc 
20160401 03:56:34< mattsc> Just press <return> when the difficulty selection is up, then hit return again right away
20160401 03:56:40< Aginor> I'll wait for you guys to resolve these issues, then I'll rebase the renderpath branch on top of it
20160401 03:56:52< vultraz> also confirmed with Enter
20160401 03:57:08< vultraz> if you press Esc really late in the loading process you can get to the storyscreen with an invalid cache
20160401 03:57:14< vultraz> ie, giant image not found
20160401 03:57:39< vultraz> (also, minimal scrollbars incoming in a bit)
20160401 03:58:29-!- ShikadiLord [~ignacio@wesnoth/developer/shadowm] has left #wesnoth-dev []
20160401 03:59:29-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160401 04:02:25-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 04:02:26< travis-ci> wesnoth/wesnoth#9152 (master - 1cc3711 : mattsc): The build has errored.
20160401 04:02:26< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119978969
20160401 04:02:26-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 04:02:49< vultraz> poor shadowm has ragequit, it seems
20160401 04:07:12 * vultraz checks his mental GUI2 checklist
20160401 04:07:21< vultraz> ok, so the scrollbars are almost done..
20160401 04:07:30< vultraz> the procedural buttons
20160401 04:07:50< vultraz> need to look at the slider issue
20160401 04:07:57< vultraz> need to look at making buttons slightly bigger..
20160401 04:09:25< Aginor> need to fix your threading so it's not race prone
20160401 04:09:51< celticminstrel> Technically that's gfgtdf's threading.
20160401 04:09:55< Aginor> ok
20160401 04:10:07< Aginor> need to fix gfgtdf's threading so it's not race prone
20160401 04:10:17< celticminstrel> And partly mine since I was also fiddling with it.
20160401 04:10:56< vultraz> I have about as much knowledge of threading as I do advanced particle physics
20160401 04:11:32< vultraz> I can't help there
20160401 04:12:37< Aginor> I don't want to get involved in it
20160401 04:13:25-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160401 04:18:57< mattsc> away /afk
20160401 04:19:05< mattsc> blargh
20160401 04:25:32-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160401 04:26:12-!- ShikadiLord [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160401 04:26:20< ShikadiLord> I want to clarify that I did not, in fact, rage quit.
20160401 04:27:12< ShikadiLord> However, being joined to the channel is a huge distraction I don't need right now.
20160401 04:27:17 * celticminstrel didn't think you did.
20160401 04:27:28-!- ShikadiLord [~ignacio@wesnoth/developer/shadowm] has left #wesnoth-dev []
20160401 04:27:34< celticminstrel> Makes sense.
20160401 04:29:36< celticminstrel> Ooh, we should pick an app category for Wesnoth.
20160401 04:30:10< vultraz> Games?
20160401 04:30:41< celticminstrel> Sure, but we can also be more specific - Action, Adventure... I guess Strategy fits best?
20160401 04:31:00< celticminstrel> This is for Mac App Store, so probably not immediately useful, but...
20160401 04:31:55< celticminstrel> ancestral: You forgot to update the version in the Info.plist.
20160401 04:32:09< vultraz> Strategy
20160401 04:32:14< vultraz> Adventure
20160401 04:32:21< celticminstrel> Can only choose one.
20160401 04:32:47< vultraz> oh?
20160401 04:32:48< vultraz> ok Strategy
20160401 04:35:55-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160401 04:42:28< celticminstrel> Ugh, this isn't working. Giving up for now, will see if ancestral can help...
20160401 04:44:16< celticminstrel> Ugh, I foolishly went and pulled, forgetting that what I was missing was the flag that forces a full compilation.
20160401 04:44:58< celticminstrel> So I'm not going to check just now if my atomic stuff fixes the crash. vultraz, could you test it quickly?
20160401 04:45:06< irker509> wesnoth: Celtic Minstrel wesnoth:master 8580245c29c7 / src/config.hpp: Complete config.hpp compiler detection https://github.com/wesnoth/wesnoth/commit/8580245c29c720b2807829e2929358d05513725a
20160401 04:45:08< irker509> wesnoth: Celtic Minstrel wesnoth:master 7c767e640257 / src/gui/dialogs/ (loadscreen.cpp loadscreen.hpp): tloadscreen: Use atomic access for current stage https://github.com/wesnoth/wesnoth/commit/7c767e64025790fe18cf8d05b526e727d8b24cf6
20160401 04:45:10< irker509> wesnoth: Celtic Minstrel wesnoth:master d958429e27f2 / projectfiles/Xcode/Info.plist: XCode: Update Wesnoth version https://github.com/wesnoth/wesnoth/commit/d958429e27f230bb3eda26c05c56ec84a2ca8696
20160401 04:45:12< irker509> wesnoth: Celtic Minstrel wesnoth:master 1ff7b5fbcd41 / projectfiles/Xcode/Info.plist: XCode: Set Mac App Store category https://github.com/wesnoth/wesnoth/commit/1ff7b5fbcd41bb48fa8a40995f0f140c09a3bc2b
20160401 04:49:36-!- travis-ci [~travis-ci@ec2-107-22-112-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 04:49:37< travis-ci> wesnoth/wesnoth#9153 (master - 1ff7b5f : Celtic Minstrel): The build failed.
20160401 04:49:37< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119985851
20160401 04:49:37-!- travis-ci [~travis-ci@ec2-107-22-112-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 04:55:44< celticminstrel> Okay, that cancels my plans for what to do next... probably.
20160401 04:56:36-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160401 04:56:44< ancestral> celticminstrel: Noted
20160401 04:56:51< celticminstrel> Ah, I see.
20160401 04:57:05< celticminstrel> It's gfgtdf's config work.
20160401 04:57:06< ancestral> And yes
20160401 04:57:17< ancestral> That reminds me
20160401 04:59:53< ancestral> vultraz: Planning any April Fools shenanigans?
20160401 05:01:10< celticminstrel> I'm not sure whether I should wrap that ifdef in "#if __cplusplus >= 201402L", or change things so it works on C++11.
20160401 05:03:26< celticminstrel> It might work on C++11 if std::less<> was replaced with std::less<something>... or it might not. I dunno.
20160401 05:05:09< vultraz> ancestral: nah
20160401 05:06:17-!- prkc [~prkc@192.40.89.11] has joined #wesnoth-dev
20160401 05:07:00< vultraz> celticminstrel: you've broken my build
20160401 05:07:27< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\config.hpp|120|error: wrong number of template arguments (0, should be 1)|
20160401 05:07:32< vultraz> C:\TDM-GCC-32\lib\gcc\mingw32\5.1.0\include\c++\bits\stl_function.h|382|note: provided for 'template<class _Tp> struct std::less'|
20160401 05:07:40< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\config.hpp|122|error: template argument 3 is invalid|
20160401 05:17:16< celticminstrel> It's more gfgtdf's fault, really.
20160401 05:17:29< celticminstrel> See what I said earlier about #if __cplusplus
20160401 05:17:34< celticminstrel> That would apply in config.hpp
20160401 05:18:07< celticminstrel> (Or we could add a HAVE_CXX14 macro to generalize it more, if we really want.)
20160401 05:20:52-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Quit: Lost terminal]
20160401 05:21:02-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160401 05:21:05< celticminstrel> I think I managed to reproduce the crash, so the use of atomics didn't fix it.
20160401 05:21:30< celticminstrel> Though it's entirely possible that this is a different crash.
20160401 05:26:35 * celticminstrel goes ahead and adds that C++14 macro.
20160401 05:27:32< vultraz> I wonder when compilers will have good support for c++14
20160401 05:27:44< irker509> wesnoth: Celtic Minstrel wesnoth:master 390aa205168a / src/ (config.hpp global.hpp): Guards around C++14 code https://github.com/wesnoth/wesnoth/commit/390aa205168aa589e6bed0f8b14692d0656d4b47
20160401 05:27:45< celticminstrel> Yours probably already does.
20160401 05:27:45< vultraz> Isn't it a more minor standard change than 11 was?
20160401 05:27:49< vultraz> And 17 will be?
20160401 05:28:20< celticminstrel> I don't know for sure, but it's not unlikely that your compiler does support it, but is being told to enforce C++11.
20160401 05:28:23-!- aeonchil1 [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160401 05:28:24-!- aeonchil1 [enchilado@defocus/yummy/enchilado] has quit [Client Quit]
20160401 05:28:34< celticminstrel> I'm not entirely sure what's new in C++14.
20160401 05:29:07< vultraz> I can try building with c++14
20160401 05:29:21< celticminstrel> Probably better not to.
20160401 05:29:32< celticminstrel> At least not right away.
20160401 05:29:51< celticminstrel> Maybe after a few releases?
20160401 05:30:01< celticminstrel> (A few = one or two)
20160401 05:30:19< celticminstrel> In any case, my compiler doesn't support it.
20160401 05:31:16-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Quit: Lost terminal]
20160401 05:31:28-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160401 05:32:18-!- travis-ci [~travis-ci@ec2-54-92-147-78.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 05:32:19< travis-ci> wesnoth/wesnoth#9155 (master - 390aa20 : Celtic Minstrel): The build is still failing.
20160401 05:32:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119989586
20160401 05:32:19-!- travis-ci [~travis-ci@ec2-54-92-147-78.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 05:32:20< celticminstrel> So vultraz, can you tell me if my push does anything about a) the stage name inconsistency you mentioned or b) the crash?
20160401 05:32:29< celticminstrel> :(
20160401 05:32:34< vultraz> I'm building with 14
20160401 05:32:42< celticminstrel> I really think that's a bad idea.
20160401 05:32:58< vultraz> ..ok this is broken a'f
20160401 05:32:59< celticminstrel> You'll end up accidentally committing things that break everything.
20160401 05:33:11< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\about.cpp|160|warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:|
20160401 05:33:32< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\config.hpp|302|error: no type named 'type' in 'struct boost::enable_if<boost::is_base_of<enum_tag, config::attribute_value>, config::attribute_value&>'|
20160401 05:35:00< celticminstrel> Travis doesn't like the atomics, either... :|
20160401 05:35:55< vultraz> I think it's bad that you fenced off code that doesn't compile
20160401 05:36:27< celticminstrel> It does compile for gfgtdf.
20160401 05:37:39-!- NosajIRL [~nos@208.91.185.104] has quit [Ping timeout: 248 seconds]
20160401 05:37:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 05:41:05< celticminstrel> I fenced it off because it's (at least currently) not compatible with C++11.
20160401 05:41:21< celticminstrel> Since we're targeting C++11, anything not compatible needs to be fenced off.
20160401 05:42:26< celticminstrel> I wonder if it could be made C++11-compatibile by specializing std::less<void>...
20160401 05:42:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160401 05:48:46< vultraz> I'm going to see if I can build with 11
20160401 05:49:08< celticminstrel> ancestral: Do you have any idea if there's a way to suppress the Wesnoth dock icon if Wesnoth is being run without GUI?
20160401 05:50:15< celticminstrel> I tried a few things which seemed to be partly successful.
20160401 05:50:34< celticminstrel> I'm wondering if SDL is interfering.
20160401 05:50:57< ancestral> Suppress the icon?
20160401 05:51:03< celticminstrel> Yeah.
20160401 05:51:08< ancestral> Oh
20160401 05:51:18< celticminstrel> I know it can be suppressed with an Info.plist key.
20160401 05:51:33< celticminstrel> And there's a way to dynamically bring it back, but if I do that, you don't get the bouncing stage.
20160401 05:51:47< ancestral> If you run the ./MacOS app that might work, as opposed to open
20160401 05:51:54< celticminstrel> (Maybe you would if I did that earlier, prior to command-line options.)
20160401 05:52:21< celticminstrel> No, I get a dock icon when it's launched from the command-line. (For example, when running WML unit tests.)
20160401 05:52:42-!- Kwandulin [~Miranda@p200300760F191CFF6DB579CAC467FCA9.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160401 05:52:43< ancestral> Wait, that doesn’t work
20160401 05:57:15< fendrin> hello
20160401 05:57:35< celticminstrel> I tried adding LSUIElement=true to the Info.plist, and I tried using TransformProcessType.
20160401 06:11:01< celticminstrel> Several uses of BOOST_FOREACH depended on including utils/foreach.hpp.
20160401 06:11:35< vultraz> heh
20160401 06:11:47< vultraz> I guess their files never included the boost header directly
20160401 06:12:14< celticminstrel> The funnier thing is that they didn't even use FOREACH.
20160401 06:12:20< celticminstrel> (So far.)
20160401 06:13:52< vultraz> #JustOldCodebaseThings
20160401 06:14:06< vultraz> celticminstrel: ok, I was able to build with 11 again after your last commit
20160401 06:14:26< vultraz> celticminstrel: I no longer get the crash
20160401 06:14:31< vultraz> instead, it exists the loadscreen
20160401 06:14:44< vultraz> so pressing esc or enter when starting wesnoth will cancel startup
20160401 06:14:58< vultraz> ah wait
20160401 06:15:02< vultraz> I have an assert
20160401 06:15:14< vultraz> config_cache.cpp:411
20160401 06:15:30< celticminstrel> When you say "exits loadscreen" do you mean "exits wesnoth" or "skips to titlescreen"?
20160401 06:15:45< vultraz> depends on where you do it
20160401 06:15:53< vultraz> if loading a campaign, it will return to titlescreen
20160401 06:16:00< vultraz> crap, now i have a scoped_ptr assert
20160401 06:16:28< vultraz> yeah, crap's still broken
20160401 06:16:35< celticminstrel> Hmm, I guess that could be considered a feature... but enter shouldn't do anything.
20160401 06:16:38< celticminstrel> Only escape.
20160401 06:17:07< vultraz> and now it's a runtime error
20160401 06:17:14< vultraz> somehow, the error has degraded
20160401 06:17:30< vultraz> worked, assert in config cache, then an scoped ptr assert, now runtime error
20160401 06:22:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160401 06:27:53< celticminstrel> vultraz: Where's the scoped pointer?
20160401 06:27:58< celticminstrel> ie, what's the stack trace
20160401 06:28:08< celticminstrel> (Or is that all the same error?)
20160401 06:34:13-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160401 06:36:23-!- NosajIRL [~nos@208.91.185.104] has joined #wesnoth-dev
20160401 06:39:32-!- NosajIRL [~nos@208.91.185.104] has quit [Read error: Connection reset by peer]
20160401 06:39:45-!- nos_ [~nos@208.91.185.104] has joined #wesnoth-dev
20160401 06:42:29< zookeeper> gui/dialogs/loadscreen.hpp(82) has something broken
20160401 06:42:42< zookeeper> Microsoft Visual Studio 12.0\VC\include\atomic(545): error C2664: 'void std::_Atomic_impl<4>::_Store(void *,const void *,std::memory_order) volatile' : cannot convert argument 1 from 'volatile std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<const _Kty,_Ty>>>> *' to 'void *'
20160401 06:43:39< celticminstrel> ...what.
20160401 06:44:13 * celticminstrel sigh.
20160401 06:44:50< celticminstrel> Three different builds have three different errors on that atomic stuff; maybe I should just do that in a different way somehow... :|
20160401 06:45:47< celticminstrel> But really, what? Can't convert T* to void*? That doesn't even make... oh wait. Wait. zookeeper, does removing the volatile keyword in that header fix it?
20160401 06:46:12< celticminstrel> In loadscreen.hpp.
20160401 06:46:46< celticminstrel> "Can't convert T* to void*" doesn't make sense, but "can't convert volatile T* to void*" does.
20160401 06:47:34< celticminstrel> It probably doesn't need volatile anyway, the atomicness is an even stronger constraint than volatile provides.
20160401 06:47:40< zookeeper> apparently
20160401 06:47:52< celticminstrel> Okay, shall I commit it or you?
20160401 06:47:57< zookeeper> not me
20160401 06:48:01< zookeeper> but i haven't finished compiling
20160401 06:48:09< zookeeper> so can't know for sure
20160401 06:48:17< celticminstrel> 'kay, I'll wait until you're sure.
20160401 06:48:37< zookeeper> someone could fix this too so it doesn't get in my face 100 times per compile: fake_unit_ptr.hpp(73): warning C4800: 'unit *' : forcing value to bool 'true' or 'false' (performance warning)
20160401 06:49:04< celticminstrel> Hmm.
20160401 06:50:29< celticminstrel> That seems like a not-very-useful warning... maybe it should be suppressed. (Which means I won't be the one to do it.)
20160401 06:56:09-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160401 06:59:15-!- nos_ is now known as NosajIRL
20160401 07:18:32< zookeeper> celticminstrel, worked
20160401 07:19:58< celticminstrel> Maybe that'll fix the Travis error too, if I'm lucky... 
20160401 07:25:25< fendrin> No april fool news this year?
20160401 07:30:04-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 268 seconds]
20160401 07:33:45-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160401 07:33:56-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has left #wesnoth-dev []
20160401 07:37:52< zookeeper> i guess not
20160401 07:38:54-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160401 07:53:05-!- NosajIRL [~nos@208.91.185.104] has quit [Remote host closed the connection]
20160401 07:56:31-!- nos_ [~nos@208.91.185.104] has joined #wesnoth-dev
20160401 07:56:58-!- celticminstrel is now known as celmin|sleep
20160401 08:01:42< irker509> wesnoth: Celtic Minstrel wesnoth:master cc115b9d0ed9 / src/gui/dialogs/loadscreen.hpp: tloadscreen fixup for MSVC https://github.com/wesnoth/wesnoth/commit/cc115b9d0ed932a59cbae9a60341c348502d138f
20160401 08:09:13-!- travis-ci [~travis-ci@ec2-107-22-112-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 08:09:14< travis-ci> wesnoth/wesnoth#9156 (master - cc115b9 : Celtic Minstrel): The build is still failing.
20160401 08:09:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120008450
20160401 08:09:14-!- travis-ci [~travis-ci@ec2-107-22-112-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 08:20:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 08:21:27-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 264 seconds]
20160401 08:24:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160401 08:33:14-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160401 08:33:20-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160401 08:35:48< Soliton> so the moment threads are introduced people wonder whether random types are somehow guaranteed to be atomic and random crashes occur...
20160401 08:38:44-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160401 08:45:31< zookeeper> hush. we're professionals, don't worry.
20160401 08:49:51-!- nos_ is now known as NosajIRL
20160401 08:52:08< vultraz> zookeeper: do you really really think the buttons need slightly rounded edges?
20160401 08:54:52< zookeeper> yes
20160401 08:56:07< vultraz> zookeeper: https://drive.google.com/file/d/0B-mR9s8FduLLSnl4U0FUWFptVjA/view?usp=sharing
20160401 08:56:40< zookeeper> looks like the one i last yesterday
20160401 08:56:42< zookeeper> +saw
20160401 08:57:00< zookeeper> oh, except the gradient is there now
20160401 08:57:00< vultraz> has gradient background now
20160401 08:58:55< vultraz> I don't really like the rounded corners, but oh well..
20160401 09:00:43< zookeeper> but i don't know what that image is supposed to show me, aside from the gradient.
20160401 09:00:55< zookeeper> or what you assume from the fact that i'm not saying anything.
20160401 09:01:32< vultraz> whether you think it's sufficiently good to go in
20160401 09:02:43< zookeeper> uh
20160401 09:05:34-!- mjs-de [~mjs-de@78.48.87.170] has joined #wesnoth-dev
20160401 09:05:52< zookeeper> well, aside from the font looking too big and/or too high, the buttons are still not as rounded as before and you've omitted the subtler shading touches
20160401 09:06:55< zookeeper> it's noticeably flatter and less elegant now
20160401 09:09:29-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160401 09:10:26< vultraz> I say it's more elegant for being simpler
20160401 09:11:30< vultraz> also, it's exactly as rounded as before
20160401 09:13:06< zookeeper> it's not, as the roundedness doesn't come from counting the orange border pixels, but also from the surroundings
20160401 09:14:41< vultraz> such single-pixel details are hard to do from WML :|
20160401 09:17:29< zookeeper> and you knew that when you started
20160401 09:17:33< zookeeper> surely
20160401 09:18:29< vultraz> I wasn't expecting to be expected to make it rounded
20160401 09:19:26< vultraz> since I wasn't intended to do a 1-to-1 conversion
20160401 09:20:38< zookeeper> who did you consult on what the expectations should be?
20160401 09:21:10-!- Kwandulin [~Miranda@p200300760F191CFF6DB579CAC467FCA9.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160401 09:22:47-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: End Transmission.]
20160401 09:23:59< vultraz> I just didn't intend to do an exact conversion
20160401 09:24:02< zookeeper> https://dl.dropboxusercontent.com/u/63964618/wesnoth/buttons.gif
20160401 09:24:08< vultraz> I was trying to experiment with new designs 
20160401 09:26:47< vultraz> yes, it's deliberately simpler
20160401 09:30:09< zookeeper> if you want to experiment with new designs then you need to come up with a new design, not just take the existing one and make it simpler and flatter because that's what smartphone UI's look like now, or wherever your aesthetic reasoning originates from. if the current UI was meant to be flat and simple then that's what it'd look like already, but it doesn't.
20160401 09:31:12< vultraz> The current UI was simply a reskin of the old UI
20160401 09:31:17< vultraz> remember?
20160401 09:32:18< zookeeper> yeah
20160401 09:32:55< zookeeper> although buttons have always been rather physical-looking
20160401 09:36:06< zookeeper> it doesn't sound like rocket science to me to change the color of the bottom and left orange lines and draw one 2px diagonal brighter line in the top right corner, trim that extra 1px off the ends of both bright blue lines and then add a simple shadow effect to bottom right by two dark lines
20160401 09:37:03< zookeeper> then it'd look almost indistinguishable at least with my eyes, and you could pursue your redesigns separately later
20160401 09:37:33-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 276 seconds]
20160401 09:44:45< vultraz> I'll just work on the redesign.
20160401 09:44:50< vultraz> This is all related to the new font
20160401 09:44:57< vultraz> Since it's slightly bigger, the buttons look too small.
20160401 09:51:51< vultraz> I'm considering a bump of 4 px in height
20160401 09:55:00-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160401 09:58:58-!- Kwandulin [~Miranda@p200300760F191CFF88955DF007C5F6D5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160401 10:22:57-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 260 seconds]
20160401 10:32:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 10:36:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160401 10:38:22-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160401 10:41:35-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160401 10:54:32< vultraz> zookeeper: this is the new design I was imagining https://drive.google.com/file/d/0B-mR9s8FduLLTWQ5NXdlYl9YM2s/view?usp=sharing
20160401 10:54:41< vultraz> obviously needs better colors
20160401 10:54:44< vultraz> but you get the idea
20160401 10:57:32< vultraz> I need to consult jet
20160401 10:58:22< zookeeper> i was hoping i'd have something positive to say
20160401 10:58:27< zookeeper> but i can't lie
20160401 10:59:05< vultraz> There's not enough contrast without the borders
20160401 11:00:10< vultraz> I didn't expect positive feedback :P
20160401 11:00:13< vultraz> it looks off even to me
20160401 11:00:51< zookeeper> it looks like the flattest smartphone UI theme, or perhaps some 80's GUI
20160401 11:01:28< vultraz> Again, I need to talk to some artists
20160401 11:01:50< vultraz> I don't care if it looks like a smartphone theme, but I do care if it looks like something from the 80's
20160401 11:01:52< vultraz> *shudder*
20160401 11:05:42< zookeeper> reminiscient of this kind of GUI's, due to the flatness combined with poor attempt at depth by borders: https://www.google.fi/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwjHxq_Ope3LAhVIkSwKHZjSA0wQjRwIBw&url=http%3A%2F%2Fwww.sebastianbauer.info%2Findex.php%3Fpage%3Damiga%2Ffreeciv&bvm=bv.118443451,d.bGg&psig=AFQjCNHTGQeM71cmsjzz3hGaX_Ah6dPOqQ&ust=1459595095804858
20160401 11:05:48< zookeeper> whoops
20160401 11:05:58< zookeeper> meant http://www.sebastianbauer.info/amiga/freeciv-main.png
20160401 11:06:40< vultraz> that looks horrendous :|
20160401 11:07:19< zookeeper> yeah, we don't want that, do we?
20160401 11:07:41< vultraz> but dammit, it's a button. How many ways can you decorate a rectangle
20160401 11:08:08< zookeeper> hundreds
20160401 11:08:44-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160401 11:09:54< vultraz> I'm trying to transition towards a simpler, cleaner UI design
20160401 11:10:42< Kwandulin> The glassy end turn button looks nice. How about something like that?
20160401 11:10:47< zookeeper> yes, that's what you keep saying. what i keep missing is the "why" and also whether anyone else actually agrees.
20160401 11:11:09< vultraz> I feel it looks better in certain cases
20160401 11:11:14< vultraz> For example
20160401 11:11:21< vultraz> The simpler window border look better
20160401 11:11:26< vultraz> especially in the titlescreen panels
20160401 11:12:25< vultraz> Or when I adjusted the title label styling
20160401 11:12:54< vultraz> I'd like the UI to feel modern
20160401 11:13:57< vultraz> So the "why" is basically, "because it's modern"
20160401 11:16:05< zookeeper> yes, everyone knows you think modern means rectangular and flat and simple, because that's the current commercial UI trend
20160401 11:20:12< vultraz> Exactly
20160401 11:20:20< zookeeper> exactly.
20160401 11:20:24< vultraz> Is there anything wrong with that?
20160401 11:23:02< zookeeper> yes, it's a case of sticking oneself in a box of unimaginatively copying whatever someone else already did. if the commercial UI trend was shiny, super-rounded balloony bullons, then you'd be doing that, "because it's modern".
20160401 11:24:47< zookeeper> you know what i think is actually modern? rounded corners, drop shadows, making things actually look nice and original enough that it's distinct but not too different in a confusingly way, instead of looking more or less like everything else except with different colors.
20160401 11:25:39< vultraz> I'd *love* drop shadows in certain places
20160401 11:26:29< zookeeper> apparently not behind dialogs :p
20160401 11:28:46< vultraz> That's a problem with GUI2
20160401 11:28:58< vultraz> You don't have access to the canvas outside the rectangular area defined by a widget
20160401 11:29:08< zookeeper> that's not very surprising, pretty much everything seems to be a problem with GUI2 :p
20160401 11:30:27< zookeeper> although it seems logical enough that a widget wouldn't draw its own drop shadow, but that the parent widget/window/whatever would.
20160401 11:33:45< wedge009> This is not a comment on the hard work that goes into Wesnoth, but I will say that I really don't like the flat so-called 'modern' look presented in Windows 8/10. I find it funny that they touted Vista/7's glassy Aero look and then simply to cater for the far-weaker graphical capabilities of phones and other mobile devices they went in completely the opposite direction with the Metro/ModernUI look.
20160401 11:35:09< wedge009> One could argue a similar thing happened with Oxygen->Air->Breeze in KDE, but I don't mind that so much because Linux is more of a secondary OS for me and if you really wanted to, you have the freedom to change to other designs or even other desktop environments.
20160401 11:36:37< wedge009> I suppose I've always been a step behind when it comes to Windows, though. Even on XP I kept the 'classic' look option from 3.x days, and didn't adopt 7 until XP expired and even then it was more related to having 64-bit memory addressing than anything else.
20160401 11:37:09< vultraz> I've always tried to have the latest OS
20160401 11:37:13< vultraz> I updated to 10 a week after it launched
20160401 11:39:18< wedge009> I have 10 only on my laptops which came with 8. I know some people who loved the touchy-feely mobile oriented 8 hate the 'step backwards' that is 10, but I think it's a good compromise with the older desktop paradigm and tries to counter the negative feedback surrounding 8. That said there's a lot I still don't like about 10, but that's more to do with its non-UI aspects.
20160401 11:40:28< wedge009> Even so, 10's UI still isn't as polished as I think they want it to be. There are still some left overs in Vista/7 style, though the inconsistency isn't as prevalent as it was in 8.
20160401 11:40:45-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 248 seconds]
20160401 11:44:02-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160401 11:54:10-!- ideuler [~textual@gwcesium.di.uminho.pt] has joined #wesnoth-dev
20160401 11:54:41-!- ideuler [~textual@gwcesium.di.uminho.pt] has quit [Client Quit]
20160401 11:58:36-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160401 12:04:36-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has left #wesnoth-dev []
20160401 12:05:28-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160401 12:06:14-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160401 12:07:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160401 12:07:33-!- wedge010 is now known as wedge009
20160401 12:10:43< irker509> wesnoth: Wedge009 wesnoth:master 59a8682b8915 / src/log.hpp: Trivial comment spelling correction (from PR #640). https://github.com/wesnoth/wesnoth/commit/59a8682b8915a47962c4afcec7c64c11b2e0040e
20160401 12:15:30-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 12:15:31< travis-ci> wesnoth/wesnoth#9158 (master - 59a8682 : Wedge009): The build is still failing.
20160401 12:15:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120051036
20160401 12:15:31-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 12:19:45< wedge009> I don't know much about C++ in Travis, but it's been failing for a while now, hasn't it? Looks related to some build or start-up options for the tests.
20160401 12:37:17-!- Kwandulin [~Miranda@p200300760F191CFF88955DF007C5F6D5.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20160401 12:42:34-!- ideuler [~textual@gwcesium.di.uminho.pt] has joined #wesnoth-dev
20160401 12:57:00< wedge009> This new loadscreen.hpp - it seems to not work with VC14 atomic template.
20160401 12:59:28< wedge009> At line 82, the current_stage member. It requires const_iterator to be 'trivially copyable'.
20160401 12:59:52-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 260 seconds]
20160401 12:59:58< vultraz> wedge009: latest master?
20160401 13:00:02< vultraz> I thought celmin|sleep fixed that
20160401 13:00:05< vultraz> i mean fixed it on vs
20160401 13:01:20< wedge009> Yes, my master is current.
20160401 13:01:57< wedge009> I see in the logs he changed something specific to MSVC, but that was something to do with volatile.
20160401 13:02:12< wedge009> Something specifically for MSVC*
20160401 13:03:28< vultraz> yeah seems the loadscreen is causing problems for everyone
20160401 13:04:18-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160401 13:05:50< wedge009> Also, I missed the earlier discussion about C++11 - have we agreed to stop supporting VC9? Removing the C++11 guards in config.hpp breaks compilation on VC9.
20160401 13:05:59< wedge009> That one was yours, according to the logs.
20160401 13:06:09< vultraz> VS2013 is the new minimum
20160401 13:06:14< wedge009> Ah, okay.
20160401 13:06:22< vultraz> By merit of compiler support
20160401 13:06:31< wedge009> ...should whoever is using 2013 update the project then?
20160401 13:06:39< vultraz> celmin|sleep was going to
20160401 13:06:43< vultraz> zookeeper also have 2013
20160401 13:06:44< wedge009> Okay, cool.
20160401 13:06:46< vultraz> has
20160401 13:08:40-!- Kwandulin [~Miranda@p200300760F191C87EC5A1D779F442267.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160401 13:09:33< vultraz> I'm curious if you can build with c++14
20160401 13:09:46< vultraz> since that's broken for me.
20160401 13:10:36< vultraz> if it's a gcc thing we should put a note somewhere to fix it eventually
20160401 13:11:48< vultraz> then again, I'm on gcc 5
20160401 13:12:14-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160401 13:15:56-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160401 13:58:54-!- gfgtdf [~chatzilla@x50ab6f7b.dyn.telefonica.de] has joined #wesnoth-dev
20160401 13:59:26< gfgtdf> 20160401 03:13:25< vultraz> celticminstrel: for some reason, the display of strings on the loadscreen doesn't seem consistent..
20160401 13:59:50< gfgtdf> vultraz: that's mostlikeley just becasue the final step is very fast so it uisnt always displayed in that time.
20160401 14:00:06< vultraz> gfgtdf: no I'm talking about the final step
20160401 14:00:19< vultraz> there's a pause
20160401 14:00:30< vultraz> and the difference seems to be consistent
20160401 14:00:51< vultraz> Let me rephrase this
20160401 14:01:07< vultraz> After the final step, there's always a small pause
20160401 14:01:28< vultraz> So I do get to observe what it is
20160401 14:01:34< vultraz> and it is consistently different
20160401 14:03:29< vultraz> And now it randomly crashed
20160401 14:04:21< gfgtdf> celmin|sleep: 390aa205168a will most likeley disable that code for msvc
20160401 14:05:49< vultraz> gfgtdf: that code is broken anyway if I try to build with --std=c++14
20160401 14:06:11< gfgtdf> vultraz: what erros do you get ?
20160401 14:06:36< vultraz> [16:33:32]	vultraz	C:\Users\Charles\Documents\wesnoth-git\src\config.hpp|302|error: no type named 'type' in 'struct boost::enable_if<boost::is_base_of<enum_tag, config::attribute_value>, config::attribute_value&>'|
20160401 14:07:12-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160401 14:08:07< gfgtdf> vultraz: and you say that is related to th heterogenous lookups change ?
20160401 14:08:23< gfgtdf> vultraz: becasue this errors doesnt lok related at all
20160401 14:09:03< vultraz> i think it might have been after 8580245c29c7 
20160401 14:09:05< vultraz> let me try again...
20160401 14:11:48< vultraz> yeah something is broken in config with 14
20160401 14:12:41< vultraz> "invalid conversion from const char* to int" and similar, plus the one I pasted above..
20160401 14:13:03-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 264 seconds]
20160401 14:13:43< irker509> wesnoth: gfgtdf wesnoth:master 7e204d16e45f / src/config.hpp: fix c++14 compiler detation https://github.com/wesnoth/wesnoth/commit/7e204d16e45f643f729ace1e9c34521d0b0b2cc8
20160401 14:15:03< irker509> wesnoth: gfgtdf wesnoth:master 9d570b852c6d / src/config.hpp: fix c++14 compiler detection https://github.com/wesnoth/wesnoth/commit/9d570b852c6df3e75344997e1b33818a50b2788a
20160401 14:18:30< gfgtdf> vultraz: so it was already borken before?
20160401 14:18:59< vultraz> after 390aa205168a i was able to build with 11 again
20160401 14:19:13< vultraz> so something before that broke it, then 390aa205168a  fixed it for 11, but it's still broken for me in 14
20160401 14:19:19-!- travis-ci [~travis-ci@ec2-107-22-112-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 14:19:20< travis-ci> wesnoth/wesnoth#9159 (master - 7e204d1 : gfgtdf): The build is still failing.
20160401 14:19:20< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120077149
20160401 14:19:20-!- travis-ci [~travis-ci@ec2-107-22-112-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 14:21:08< vultraz> different errors than I had with 11, though
20160401 14:21:20< vultraz> (I think)
20160401 14:23:29< gfgtdf> vultraz: is teh error above really teh one one you gwt with c++14 ?
20160401 14:24:08-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 14:24:09< travis-ci> wesnoth/wesnoth#9160 (master - 9d570b8 : gfgtdf): The build is still failing.
20160401 14:24:09< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120077531
20160401 14:24:09-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 14:24:11< vultraz> no I get a lot of stuff like this: C:\Users\Charles\Documents\wesnoth-git\src\about.cpp|160|error: no match for 'operator=' (operand types are 'const config::attribute_value' and 'const config::attribute_value')|
20160401 14:24:21< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\about.cpp|160|error: invalid user-defined conversion from 'const config::attribute_value' to 'const char*' [-fpermissive]|
20160401 14:24:31< vultraz> also notes about code in the hetro lookup blocks
20160401 14:24:39< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\config.hpp|524|note: candidate 1: const config::attribute_value& config::operator[](const char (&)[N]) const [with int N = 6]|
20160401 14:24:40< vultraz> etc
20160401 14:25:20-!- ideuler [~textual@gwcesium.di.uminho.pt] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
20160401 14:25:25< gfgtdf> vultraz: CAN#T YOU JUST PUT THE FULL COMPILER OUT ONE A PASTEBIN ß
20160401 14:25:31< gfgtdf> sry for caps
20160401 14:26:12< gfgtdf> s/CAN#T/can't, s/ß/?
20160401 14:26:46< vultraz> http://pastebin.com/wSrGxvQj
20160401 14:30:37-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160401 14:31:42< irker509> wesnoth: gfgtdf wesnoth:master 2cfffe8bb601 / src/config.hpp: attempt to fix c++14 compilation. https://github.com/wesnoth/wesnoth/commit/2cfffe8bb6013afc9d97b0006d30266961add311
20160401 14:31:48< gfgtdf> vultraz: try that ^
20160401 14:33:45-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160401 14:38:52< celmin|sleep> vultraz: No, that was something else I fixed. wedge009, do you have MSVC 2013?
20160401 14:38:59-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 14:39:00< travis-ci> wesnoth/wesnoth#9161 (master - 2cfffe8 : gfgtdf): The build is still failing.
20160401 14:39:00< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120081353
20160401 14:39:00-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 14:39:05< celmin|sleep> vultraz: I never said I was going to update the MSVC project.
20160401 14:39:24< celmin|sleep> I said I could, but would prefer if someone else does.
20160401 14:39:29< vultraz> ohhhhh
20160401 14:39:30< vultraz> ok
20160401 14:39:33< vultraz> I misunderstood
20160401 14:40:34< celmin|sleep> "most likely meaningless on MSVC"...
20160401 14:40:53< celmin|sleep> https://drive.google.com/file/d/0B-mR9s8FduLLTWQ5NXdlYl9YM2s/view
20160401 14:41:08< celmin|sleep> ^ That looks okay, but I really do prefer the gold-outlined buttons.
20160401 14:41:24-!- atarocch [~atarocch@206.229.16.238] has joined #wesnoth-dev
20160401 14:41:39< celmin|sleep> However, the text size no longer looks like a problem, so that's good at least.
20160401 14:53:12-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160401 14:58:55< mattsc> celmin|sleep: I’ve thought about the adding/removing MAIs some more and I think there’s no way around using two different ID variables (at least not without lots of effort that is not really worth it).
20160401 14:59:33-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 240 seconds]
20160401 14:59:52< celmin|sleep> I see...
20160401 14:59:54< mattsc> The reason is that the id identifying the [data][micro_ai] tag must be unique, whereas that identifying the CAs sometimes needs to be and sometimes must not be unique.
20160401 15:00:07< celmin|sleep> Huh?
20160401 15:00:43-!- celmin|sleep is now known as celticminstrel
20160401 15:01:30< mattsc> If you add a CA with a specifically assigned ca_id, that id should be used, whether it already exists or not.
20160401 15:01:43< mattsc> s/should be/must be
20160401 15:01:55< mattsc> Otherwise it is impossible to remove it later.
20160401 15:01:59< mattsc> in some cases
20160401 15:02:07< mattsc> Which is what causes the problem with the bats
20160401 15:03:09< mattsc> However, the [data][micro_ais] tag still needs to be unique.
20160401 15:04:02< celticminstrel> Hmm...
20160401 15:04:33< celticminstrel> So if you explicitly specify a ca_id, then that should be used for the CAs but may need to be adjusted for the data?
20160401 15:04:46< mattsc> yes
20160401 15:05:11< mattsc> it’s ca_id= in the [micro_ai] tag, but other than that, yes
20160401 15:05:33< celticminstrel> Whereas if you don't explicitly specify a ca_id, the data-adjusted ID can be (should be?) used for the CAs.
20160401 15:05:58< mattsc> For adding, that’s what I would do, yes
20160401 15:06:18< mattsc> And for deleting, just use the standard id (without adjustments)
20160401 15:06:52< gfgtdf> 20160401 06:50:29< celticminstrel> That seems like a not-very-useful warning... maybe it should be suppressed
20160401 15:07:11< gfgtdf> celticminstrel: this is a useful warning.
20160401 15:07:28< gfgtdf> celticminstrel: it alreay prevented some bugs
20160401 15:08:23< celticminstrel> gfgtdf: But it's also spamming zookeeper's compiler output.
20160401 15:08:35< gfgtdf> celticminstrel: hmm some someone added bad code
20160401 15:08:47< celticminstrel> I wouldn't call that bad code.
20160401 15:08:57< celticminstrel> I suppose you could silence the warning though by comparing with nullptr.
20160401 15:09:05< celticminstrel> So feel free to do that.
20160401 15:09:59< gfgtdf> celticminstrel: so we now chnage thr ules to compileing warnings should  be fixed by the persons who have them ?
20160401 15:10:42< celticminstrel> I didn't think that was a rule, though I guess it is a good general guideline.
20160401 15:12:55< celticminstrel> Still, if you're calling it bad code, feel free to fix it.
20160401 15:13:08< gfgtdf> celticminstrel: well it gives warnings.
20160401 15:13:29< vultraz> gfgtdf: that fixes the build ty
20160401 15:14:23-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160401 15:14:37-!- NosajIRL [~nos@208.91.185.104] has quit [Ping timeout: 248 seconds]
20160401 15:17:45< vultraz> ok so I have wesnoth building with c++14
20160401 15:17:49< gfgtdf> vultraz: are there still errors in the loaingscrrrn ?
20160401 15:18:05< gfgtdf> vultraz: hmm yes we shodul also have a c++14 travis build
20160401 15:18:46< celticminstrel> I don't think we need that, but if you want to add a C++14 clang build I won't object.
20160401 15:18:59< celticminstrel> Provided of course that the clang version on Travis is sufficient.
20160401 15:19:46< gfgtdf> hmm it says clang version 3.5.0  so it shoudl be
20160401 15:20:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 15:21:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 15:21:09< vultraz> apparently in gcc 6 c++14 is default
20160401 15:21:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 15:22:10< celticminstrel> Obviously we can't have a C++14 GCC build on Travis though, even without the forcing of 4.7 (it was only using 4.8 before then, and you said 5 is needed).
20160401 15:22:24< vultraz> ...when did I say that
20160401 15:22:30< celticminstrel> gfgtdf said it.
20160401 15:22:39< vultraz> ah
20160401 15:22:47< celticminstrel> Specifically for the config change though, not for C++14 in general.
20160401 15:23:22< vultraz> gfgtdf: pressing Enter/Esc still exits from the loadscreen with an incomplete config cache 
20160401 15:23:29< vultraz> and it can crash
20160401 15:23:41< gfgtdf> vultraz: hmm rigth we shodul disable pressoing esc there
20160401 15:23:50< gfgtdf> vultraz: shouldnt be hard i think
20160401 15:24:06< gfgtdf> vultraz: not really sure how to do it though
20160401 15:24:07< celticminstrel> I was thinking that too, though the ability to cancel a decision to start a campaign isn't necessarily bad.
20160401 15:24:41< vultraz> you'd need to allow the loading thread to run through, though
20160401 15:25:05< celticminstrel> You could terminate it.
20160401 15:25:23< celticminstrel> But you'd need to invalidate the config cache or something if it was in the middle of creating that.
20160401 15:25:24< vultraz> terminating it is what causes problems here, isn't it
20160401 15:25:33< gfgtdf> tp enable c++14 i just use CXX14=true ?
20160401 15:25:33< celticminstrel> Yes, I think so.
20160401 15:25:52< celticminstrel> gfgtdf: Uh, probably not.
20160401 15:26:39< celticminstrel> You may need to edit the SConstruct as well as the .travis.yml.
20160401 15:27:33< irker509> wesnoth: Charles Dang wesnoth:master 4645d654c390 / projectfiles/CodeBlocks/wesnothd.cbp: CB: enable building wesnothd alone https://github.com/wesnoth/wesnoth/commit/4645d654c390ceba16223473301c7b6a3dd23761
20160401 15:29:05< vultraz> wonder if I should change the cb project to use 14 or keep that local
20160401 15:29:32< vultraz> not that I need anything from 14
20160401 15:30:42< celticminstrel> I think it's better to not change that.
20160401 15:32:37-!- travis-ci [~travis-ci@ec2-107-22-112-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 15:32:38< travis-ci> wesnoth/wesnoth#9162 (master - 4645d65 : Charles Dang): The build is still failing.
20160401 15:32:38< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120094730
20160401 15:32:38-!- travis-ci [~travis-ci@ec2-107-22-112-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 15:33:56< vultraz> travis doesn't like the loadscreen :|
20160401 15:34:22< celticminstrel> Yup.
20160401 15:34:30< vultraz> "/usr/include/c++/4.7/atomic:164:7: error: function ‘std::atomic<_Tp>::atomic() [with _Tp = std::_Rb_tree_const_iterator<std::pair<const std::basic_string<char>, std::basic_string<char> > >]’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘std::atomic<std::_Rb_tree_const_iterator<std::pair<const std::basic_string<char>,...
20160401 15:34:31< vultraz> ...std::basic_stri
20160401 15:34:33< vultraz> ng<char> > > >::atomic()’"
20160401 15:34:34< vultraz> what in god's name does this mean O_O
20160401 15:34:35< celticminstrel> Does no-one else get those errors locally?
20160401 15:34:38< vultraz> no..
20160401 15:34:40< celticminstrel> I don't know either.
20160401 15:35:53< gfgtdf> celticminstrel: hmm it seems to me like the sconstruct scrips checks for env['cxx0x'] while the travis check exported "export CXX11=true/false" does anyone knows how this worked '?
20160401 15:36:32< celticminstrel> gfgtdf: If you look at the .travis.yml, the scons line has something like "cxx0x=$CXX11".
20160401 15:36:49< celticminstrel> Or, at least it used to, maybe loonycyborg removed that when he made it the default.
20160401 15:37:01< vultraz> it's there
20160401 15:37:05< celticminstrel> Okay.
20160401 15:37:10< gfgtdf> celticminstrel: ok i found
20160401 15:37:41< loonycyborg> celticminstrel: I removed cxx0x option
20160401 15:37:57< loonycyborg> it always passes -std=c++11
20160401 15:38:06< loonycyborg> I could add option for c++14
20160401 15:38:14< celticminstrel> gfgtdf: ^
20160401 15:38:35< gfgtdf> loonycyborg: yes please do that
20160401 15:38:49< loonycyborg> what exact define should it add?
20160401 15:39:11< loonycyborg> beside passing c++14
20160401 15:39:21< loonycyborg> or only -std=c++14 is needed?
20160401 15:39:30-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160401 15:39:32< vultraz> oh deer
20160401 15:39:40< celticminstrel> Doesn't it just need -std=c++14? I suppose you could also -DHAVE_CXX14, but that's detected in global.hpp anyway.
20160401 15:39:41< vultraz> looks like the accl speed setter in prefs is broken...
20160401 15:40:00< celticminstrel> vultraz: Please tell me it's not your initializer list fix.
20160401 15:40:11< vultraz> I don't see what else it could be
20160401 15:40:23< celticminstrel> Didn't you test it?
20160401 15:41:33< vultraz> hmmmm
20160401 15:41:47< gfgtdf> loonycyborg: no t really sure, but i'd think -std=c++14 is enuogh.
20160401 15:42:18< celticminstrel> vultraz: Is that all you did to enable it? ^
20160401 15:42:25< vultraz> yes
20160401 15:42:37< vultraz> well, cb has a checkbox, but that's what it inserts
20160401 15:42:51< loonycyborg> ah cool
20160401 15:43:08< loonycyborg> #if __cplusplus >= 201402L
20160401 15:43:22< loonycyborg> what value does that macro have?
20160401 15:43:32< loonycyborg> is it dependent on -std option?
20160401 15:43:40< celticminstrel> Yes, should be.
20160401 15:43:56< celticminstrel> That's the standard macro defined for all C++ code.
20160401 15:44:24< vultraz> celticminstrel: found the cause
20160401 15:44:32< celticminstrel> Yay!
20160401 15:44:42< celticminstrel> It's not related to a FOREACH, is it?
20160401 15:44:51< vultraz> it broke when I replaced lexical_cast<std::string> with std::to_string in 
20160401 15:44:53< vultraz> const int selected_speed = std::find(
20160401 15:44:54< vultraz> 		  (accl_speeds_.begin()), accl_speeds_.end(), lexical_cast<std::string>(turbo_speed()))
20160401 15:44:56< vultraz> 		- (accl_speeds_.begin());
20160401 15:44:56< celticminstrel> Ah.
20160401 15:45:09< vultraz> I did remember reading that to_string could have inconsistent behavior with floating types
20160401 15:45:28< celticminstrel> lexical_cast should be more consistent since it uses the streams API.
20160401 15:45:36< vultraz> "std::to_string may yield unexpected results when used with floating point types and the return values may be substantially different from what std::cout would print, see the example.
20160401 15:46:17-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160401 15:47:06< celticminstrel> You could just revert that case to lexical_cast.
20160401 15:47:17< irker509> wesnoth: Charles Dang wesnoth:master f497d4c91949 / src/gui/dialogs/preferences_dialog.cpp: tpreferences: fixed accelerated speed slider https://github.com/wesnoth/wesnoth/commit/f497d4c919491ccc5d687a77a8fd47b8221b418c
20160401 15:47:25< vultraz> This is sad :(
20160401 15:47:36< vultraz> I had hoped to_string would replace All The Things
20160401 15:47:43< celticminstrel> Ideally it would compare the numbers rather than the strings though...
20160401 15:48:11< vultraz> set_value_labels expects a vector of tstrings
20160401 15:48:13< vultraz> (which it is)
20160401 15:48:51< vultraz> so unless you know a way to dynamically convert a vector of doubles into a vector of strings
20160401 15:49:40< celticminstrel> Obviously std::transform can do that, at the cost of a temporary vector.
20160401 15:50:21< vultraz> what is this transform you speak of?
20160401 15:50:26< celticminstrel> But perhaps better would be to not use the active label as an indication of the currently active setting.
20160401 15:50:41< vultraz> ....what?
20160401 15:50:54< vultraz> What you said makes no sense
20160401 15:51:36< celticminstrel> For example, instead of querying the slider for the currently-active label, you could query it for the index of the currently-active label.
20160401 15:52:17-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 15:52:18< travis-ci> wesnoth/wesnoth#9163 (master - f497d4c : Charles Dang): The build is still failing.
20160401 15:52:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120099520
20160401 15:52:18-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 15:52:28< celticminstrel> I should probably look at the code before saying anything else.
20160401 15:52:33< vultraz> that's an idea..
20160401 15:52:40< vultraz> but it's not really worth the change
20160401 15:52:48< loonycyborg> it doesn't build for me with -std=c++14
20160401 15:53:35< vultraz> celticminstrel: actually, I already use the index to set the pref value
20160401 15:53:42< vultraz> set_turbo_speed(lexical_cast<double>(accl_speeds_[index - 1]));
20160401 15:54:16< gfgtdf> loonycyborg: whts the error ?
20160401 15:54:24< celticminstrel> Okay, so...
20160401 15:55:07< celticminstrel> vultraz: That line you fixed is for initializing the slider when the dialog is open, right?
20160401 15:55:15< loonycyborg> gfgtdf: https://gist.github.com/loonycyborg/10f972f450d3184bc097057a5b693260
20160401 15:57:10-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160401 15:57:15< celticminstrel> Hmm... yeah, I'm thinking it's probably not worth changing now. I can't see a simple way to make it search numbers instead of strings, so if it works, let's not "fix" it.
20160401 15:57:54< gfgtdf> loonycyborg: seelms to be teh same erros taht vultraz had, are you on lastest master ?
20160401 15:58:06< loonycyborg> not sure, probably not
20160401 15:58:54-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20160401 16:00:10< gfgtdf> loonycyborg: please try on lastest master
20160401 16:00:31< loonycyborg> master seems to build fine
20160401 16:02:28-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160401 16:02:39< loonycyborg> after build will be done I'll commit scons option for c++14
20160401 16:02:43< celticminstrel> Incidentally, it was indeed trivial to make range-for work with the config's interator pairs.
20160401 16:02:54< loonycyborg> scons cxx_std=14, that's how it'll work
20160401 16:07:05< vultraz> celticminstrel: yes
20160401 16:08:18< irker509> wesnoth: Celtic Minstrel wesnoth:master 982394fe3a02 / / (80 files in 19 dirs): Remove custom FOREACH macro in favour of range-for https://github.com/wesnoth/wesnoth/commit/982394fe3a02b31b6ec182b86d213b372088c8a9
20160401 16:16:10-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160401 16:22:33-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Ping timeout: 240 seconds]
20160401 16:24:03-!- ScegfOd [637f4b7c@gateway/web/freenode/ip.99.127.75.124] has joined #wesnoth-dev
20160401 16:26:26-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 16:26:27< travis-ci> wesnoth/wesnoth#9164 (master - 982394f : Celtic Minstrel): The build is still failing.
20160401 16:26:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120104458
20160401 16:26:27-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 16:32:36-!- EdB [~edb@89.193.129.77.rev.sfr.net] has joined #wesnoth-dev
20160401 16:40:00-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160401 16:40:52< celticminstrel> Okay, I'm going to try switching the loadscreen back to using a const char* for current_stage_; I'm not sure if the atomic is necessary in this case, but I'll keep it for now.
20160401 16:46:49< irker509> wesnoth: loonycyborg wesnoth:master bb02ce7c72ab / SConstruct: scons: add option to enable using c++14 features https://github.com/wesnoth/wesnoth/commit/bb02ce7c72ab6c8bd3595fd60cd9232809dfde57
20160401 16:54:08-!- EdB [~edb@89.193.129.77.rev.sfr.net] has quit [Quit: Konversation terminated!]
20160401 16:55:56< irker509> wesnoth: gfgtdf wesnoth:master ae09f7975b0d / .travis.yml: Add c++14 test to travis https://github.com/wesnoth/wesnoth/commit/ae09f7975b0d5e07b5ee53aaaf97a456529d6740
20160401 16:56:20< gfgtdf> celticminstrel: ^not sure if that will wokr, i just copied the other code
20160401 16:56:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160401 16:56:39< celticminstrel> Well, we'll soon find out.
20160401 17:00:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160401 17:01:24< celticminstrel> So it turns out to be trivial to disable escape and enter in a GUI2 dialog.
20160401 17:01:36< celticminstrel> vultraz didn't do his research. :P
20160401 17:01:50< celticminstrel> (Or just didn't think of the need, I guess.)
20160401 17:05:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 17:06:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 17:06:55-!- esr1 is now known as esr
20160401 17:09:15< celticminstrel> ...hmm. I still get a crash on enter...
20160401 17:16:54-!- gfgtdf [~chatzilla@x50ab6f7b.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160401 17:33:50-!- Kwandulin [~Miranda@p200300760F191C87EC5A1D779F442267.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160401 17:34:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 17:34:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 17:35:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 17:35:14< celticminstrel> Looks like enter doesn't crash it anymore.
20160401 17:35:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 17:37:08< celticminstrel> Everyone, see if you can get the loading screen to crash now!
20160401 17:37:11< irker509> wesnoth: Celtic Minstrel wesnoth:master b7d671218451 / src/gui/dialogs/ (loadscreen.cpp loadscreen.hpp): tloadscreen: Disable escape/enter and avoid use of atomic iterator https://github.com/wesnoth/wesnoth/commit/b7d6712184518fb11a65acce2ae2283a2e99116f
20160401 17:41:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 17:42:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 17:47:59-!- mjs-de [~mjs-de@78.48.87.170] has quit [Remote host closed the connection]
20160401 18:00:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 18:01:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 18:02:24-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160401 18:15:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 18:18:35-!- Kwandulin [~Miranda@p200300760F191C87B968F1BF4F442C69.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160401 18:21:44-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 18:21:45< travis-ci> wesnoth/wesnoth#9167 (master - b7d6712 : Celtic Minstrel): The build has errored.
20160401 18:21:45< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120123962
20160401 18:21:45-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 18:22:00< celticminstrel> Sounds like an improvement.
20160401 18:22:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 18:24:43< celticminstrel> So right now, it's just a unit test failure, I think.
20160401 18:24:53< celticminstrel> And the error in the play-test in the optimized build.
20160401 18:25:28-!- Elvish_Hunter [~elvish_hu@wesnoth/developer/elvish-hunter] has joined #wesnoth-dev
20160401 18:25:50< celticminstrel> I could probably fix the unit tests if I could just get past my dynamic linking errors.
20160401 18:26:34< celticminstrel> Wait no it was a mysterious segfault in Boost.Filesystem.
20160401 18:26:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 18:28:05< celticminstrel> Hmm, the C++14 Travis build isn't working.
20160401 18:28:33< celticminstrel> The errors I'm seeing look like lack of C++14 support, which is weird.
20160401 18:30:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 18:38:34-!- horrowind [~Icedove@2a02:810a:83c0:1c18:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160401 18:39:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 18:42:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 18:44:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 18:57:26-!- atarocch [~atarocch@206.229.16.238] has quit [Remote host closed the connection]
20160401 19:03:17-!- prkc [~prkc@192.40.89.11] has quit [Ping timeout: 260 seconds]
20160401 19:04:23-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160401 19:07:41-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 248 seconds]
20160401 19:12:33-!- fendrin [~quassel@wesnoth/developer/fendrin] has quit [Ping timeout: 240 seconds]
20160401 19:14:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160401 19:18:44-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has joined #wesnoth-dev
20160401 19:20:47-!- peterK [41be90ae@gateway/web/freenode/ip.65.190.144.174] has joined #wesnoth-dev
20160401 19:21:28< peterK> Is it a common thing for the debug build of wesnoth to be super slow? Or is that a me and my setup thing?
20160401 19:22:41< celticminstrel> Not sure...
20160401 19:22:49< celticminstrel> How slow is super-slow?
20160401 19:22:54-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160401 19:24:29< peterK> Like click a button, wait a minute or two. Button action completess. I should time it for you.  :p
20160401 19:24:37< peterK> doesn't do that on release build
20160401 19:24:47< peterK> obviously
20160401 19:24:48< celticminstrel> Ah. I don't think that's normal, no. It's not that slow for me, certainly.
20160401 19:24:54< zookeeper> uh... no, it obviously shouldn't be _that_ slow
20160401 19:25:08< celticminstrel> There were some reports of 1.12.5 being super-slow on Mac, as well, and that's not even debug build...
20160401 19:25:26 * celticminstrel is assuming you're talking about master though.
20160401 19:25:50< peterK> Yeah, I just grabbed the head of the repo I think
20160401 19:26:05< peterK> I am trying to finally make good on my desire to contribute somewhere 
20160401 19:26:13< peterK> in the open source world
20160401 19:26:38< celticminstrel> What platform? Might be relevant.
20160401 19:26:57< peterK> ubuntu 14.04
20160401 19:27:22< celticminstrel> And you're building with scons?
20160401 19:27:33< celticminstrel> Or CMake, or CodeBlocks?
20160401 19:27:37< peterK> running on a lenovo t450s. Not sure what the specs are. It's work issued. Yeah scons
20160401 19:27:57< celticminstrel> (Speaking of CMake, I think it needs updating.)
20160401 19:28:06< celticminstrel> (eg, to default to C++11)
20160401 19:29:10< celticminstrel> scons is probably the most "official" way to build Wesnoth.
20160401 19:29:32< peterK> That's what I figured from the wiki
20160401 19:29:40< peterK> just tried to follow instructions
20160401 19:29:46< peterK> been awhile since I've been in c++
20160401 19:29:48< celticminstrel> ...though as far as I know it doesn't currently work on Mac. Maybe someone should fix that. (*expects self to be volunteered*)
20160401 19:31:11< peterK> Whaaaaa!? Nvm. Fixed itself.
20160401 19:31:23< peterK> I was trying out cinnamon on ubuntu
20160401 19:31:23< celticminstrel> Really?
20160401 19:31:28< celticminstrel> Huh?
20160401 19:31:29< peterK> screwed up all kinds of stuff
20160401 19:31:32< peterK> particularly chrome
20160401 19:31:42< peterK> chrome was nigh unusable too
20160401 19:31:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 19:31:45< celticminstrel> So you're saying it was a problem with your system maybe?
20160401 19:31:49< peterK> ye
20160401 19:31:52< peterK> yes, exactly
20160401 19:31:54< celticminstrel> BTW, can anyone get the loading screen to crash now?
20160401 19:32:02< celticminstrel> eg by pressing escape or enter
20160401 19:32:17< celticminstrel> Though possible other ways too, not sure.
20160401 19:32:24< peterK> I just tried, and it segfaulted
20160401 19:32:36< celticminstrel> Escape/enter at least should be fixed, I'm just not sure that was the only... 
20160401 19:32:45< celticminstrel> Did you pull in the last, uh, two hours?
20160401 19:32:48< peterK> nope
20160401 19:32:52< peterK> I was just about to say, heh
20160401 19:33:19< celticminstrel> I'm just not sure if enter/escape were the only routes to that error.
20160401 19:33:23< peterK> ah
20160401 19:33:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 19:33:57< celticminstrel> I suppose I should've also tried clicking and space...
20160401 19:34:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 19:34:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 19:34:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 19:38:12< Elvish_Hunter> celticminstrel: I just segfaulted by clicking :/
20160401 19:38:24< celticminstrel> :/
20160401 19:38:38< celticminstrel> I would assume click_dismiss is false by default though...
20160401 19:38:41< Elvish_Hunter> And now it doesn't happen...
20160401 19:38:50< celticminstrel> I'll see if explicitly setting it false changes anything.
20160401 19:39:02< celticminstrel> Yeah, these errors have been inconsistent from the start...
20160401 19:39:15< celticminstrel> I guess I'll also see if I can cause this by clicking first.
20160401 19:42:02< celticminstrel> ...what the heck is the "enginerefac" logdomain for? It's used in save_index.cpp.
20160401 19:47:29< celticminstrel> zookeeper: There's a comment near the top of gettext_boost.cpp which makes me wonder if it'll compile without that <boost/thread.hpp> include.
20160401 19:48:26< celticminstrel> Of course I can check myself, but since the comment specifically references MSVC...
20160401 19:50:21< celticminstrel> vultraz: Do you think we should phase out boost::function and boost::bind in favour of the C++11 versions?
20160401 19:50:50-!- peterK [41be90ae@gateway/web/freenode/ip.65.190.144.174] has quit [Ping timeout: 250 seconds]
20160401 19:51:17< celticminstrel> There's one detail about the C++11 versions that I dislike though - the placeholders are not in the global namespace, so you need to either write std::placeholders::_1 or have "using namespace std::placeholders" in every function (or file) that uses them.
20160401 19:51:58< zookeeper> celticminstrel, well, master now gives me the same kind of error about something atomic as before.
20160401 19:52:22< celticminstrel> Huh? About converting volatile T* to void*?
20160401 19:52:35< celticminstrel> (Where T is some complicated-looking type.)
20160401 19:52:44< celticminstrel> (Or maybe not complicated, I dunno.)
20160401 19:53:30< zookeeper> Microsoft Visual Studio 12.0\VC\include\xxatomic(229): error C2664: 'std::_Atomic_address &std::_Atomic_address::operator =(const std::_Atomic_address &)' : cannot convert argument 1 from 'const char *' to 'void *'
20160401 19:53:30< zookeeper> src\gui/dialogs/loadscreen.hpp(82) : see reference to class template instantiation 'std::atomic<const char *>' being compiled
20160401 19:53:33< zookeeper> that kind of stuff
20160401 19:53:44< celticminstrel> Hmm.
20160401 19:54:01< celticminstrel> Okay, so it must be because std::atomic is specialized for pointer types.
20160401 19:54:21< celticminstrel> Indeed, converting from const char* to void* shouldn't be allowed (you'd want const void* instead).
20160401 19:54:42< celticminstrel> I'll think about how to fix this.
20160401 19:56:57-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has quit [Remote host closed the connection]
20160401 19:57:58< celticminstrel> I might have to just const_cast it... :|
20160401 19:58:37< celticminstrel> Though I suppose I could limit such a monstrosity to MSVC 2013 only...
20160401 19:58:51-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 19:59:21< celticminstrel> Still, I think it's safe to const_cast away a const as long as you're not actually modifying the value through the result.
20160401 19:59:38< celticminstrel> (Though I guess it could interfere with optimizations.)
20160401 20:01:20-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 20:01:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20160401 20:01:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 20:02:05< celticminstrel> zookeeper: So did you see if that thread include seems unnecessary?
20160401 20:03:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 20:03:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 20:07:10< zookeeper> celticminstrel, i didn't try since it seemed unrelated to the current error
20160401 20:07:25< celticminstrel> Yeah, definitely unrelated.
20160401 20:08:01< celticminstrel> Since I have no other ideas, I think I'm going to go with the guarded const_cast...
20160401 20:14:37-!- gfgtdf [~chatzilla@x50ab6f7b.dyn.telefonica.de] has joined #wesnoth-dev
20160401 20:14:52< celticminstrel> gfgtdf: Just to be sure, you don't get a compiler error in the loadscreen, right?
20160401 20:19:22< gfgtdf> celticminstrel: hmm ddint test with current master, i mast build is from my latest changes to loadscreen.hpp/cpp
20160401 20:19:36< celticminstrel> Huh?
20160401 20:19:46< celticminstrel> You were working on the loadscreen too?
20160401 20:20:44< gfgtdf> celticminstrel: well yes i added the thread thing.
20160401 20:21:05< celticminstrel> But that was earlier.
20160401 20:21:09 * celticminstrel confused now.
20160401 20:21:23< gfgtdf> celticminstrel: yes whta i mean is that i didnt buidl master recently
20160401 20:21:27< gfgtdf> build*
20160401 20:21:41< celticminstrel> Ah.
20160401 20:22:31< gfgtdf> celticminstrel: all i know is that after my latest changes (froma  day ago) to it it compiled
20160401 20:22:50< celticminstrel> But you haven't tried it since I changed things?
20160401 20:23:26< celticminstrel> zookeeper is getting an error, and I'd like to know if it's specific to his version or all MSVC versions.
20160401 20:25:38< gfgtdf> celticminstrel: hmm it seems liek the c++14 build fails
20160401 20:25:51< celticminstrel> Yeah, I noticed that too.
20160401 20:26:48< gfgtdf> celticminstrel: hmm maybe he doesnt know std=c++14 and want c++1y, but accoring to http://clang.llvm.org/cxx_status.html std=c++14 issupported snce 3.5 
20160401 20:29:04< irker509> wesnoth: gfgtdf wesnoth:master 90cd3bacc826 / .travis.yml: attempt to fix travis c++14 build https://github.com/wesnoth/wesnoth/commit/90cd3bacc826943569e662498ae867a23163cf9e
20160401 20:32:28< gfgtdf> celticminstrel: y, cpnfig.hpp was change so i mostlikeley need a full rebuild, coudl take some time
20160401 20:32:59< celticminstrel> Ah yes, I added the iterator_pair include to it.
20160401 20:35:45< irker509> wesnoth: gfgtdf wesnoth:master b847c1878559 / src/fake_unit_ptr.hpp: fix msvc compilation. https://github.com/wesnoth/wesnoth/commit/b847c1878559b21875f195fde205c05311ea1164
20160401 20:35:47< irker509> wesnoth: gfgtdf wesnoth:master aaf9cb406f79 / src/menu_events.cpp: fix a c++11 todo https://github.com/wesnoth/wesnoth/commit/aaf9cb406f796db848c544a15197e360ef91ff69
20160401 20:39:49-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160401 20:41:43< gfgtdf> i wonder whether we can now remove all the '_MSC_VER' cheks for older msvc versions
20160401 20:41:50< celticminstrel> Probably.
20160401 20:42:05< celticminstrel> Figure out what's the earliest number that indicates MSVC 2013, remove older ones.
20160401 20:42:59< gfgtdf> celticminstrel: hmm well do we use a feature from which we know that isn not supported bewfore 2013 ?
20160401 20:43:20< celticminstrel> I have no idea.
20160401 20:43:55< gfgtdf> hmm i'd say we wait with that until we actuall use suhc a feaut taht is onyl suppoerted since 2013
20160401 20:47:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 20:48:10< wedge009> celticminstrel: VC14/2015 for me.
20160401 20:48:30< celticminstrel> Ah, so updating the project to 2013 isn't really feasible for you?
20160401 20:50:14< celticminstrel> I can do it, but it won't happen anytime soon.
20160401 20:50:17< wedge009> I could update it to 2015. (:
20160401 20:50:28< gfgtdf> celticminstrel: it'd be good if we coudl make cmake/sonscipt autmatically generate msvc projectfiles
20160401 20:50:30< wedge009> No rush, I suppose. VC users seem to be quite few.
20160401 20:50:54< gfgtdf> but last time i checke the cmake generated mdsvc projectfiles had some major flaws
20160401 20:50:58< gfgtdf> checked*
20160401 20:52:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 20:56:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160401 20:56:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160401 20:59:31-!- mjs-de [~mjs-de@p508C8D35.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160401 20:59:45-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 268 seconds]
20160401 21:07:19< celticminstrel> gfgtdf: So, no issues with loadscreen?
20160401 21:10:28-!- Kwandulin [~Miranda@p200300760F191C87B968F1BF4F442C69.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160401 21:14:07-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160401 21:17:42-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 21:17:43< travis-ci> wesnoth/wesnoth#9169 (master - 90cd3ba : gfgtdf): The build has errored.
20160401 21:17:43< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120166503
20160401 21:17:43-!- travis-ci [~travis-ci@ec2-54-198-118-249.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 21:22:32< wedge009> Last commit seems to work for VC14.
20160401 21:22:56< celticminstrel> Okay, so I'll go with the hacky const_cast and VC13 detection.
20160401 21:23:20< celticminstrel> Though I'm not quite sure what value of _MSC_VER I need to test against.
20160401 21:25:11-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has joined #wesnoth-dev
20160401 21:25:12< travis-ci> wesnoth/wesnoth#9170 (master - aaf9cb4 : gfgtdf): The build has errored.
20160401 21:25:12< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/120168044
20160401 21:25:12-!- travis-ci [~travis-ci@ec2-54-145-247-194.compute-1.amazonaws.com] has left #wesnoth-dev []
20160401 21:27:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160401 21:32:35< gfgtdf> celticminstrel: current master compiler succesfully
20160401 21:32:48< gfgtdf> celticminstrel: which const_cast  you mean ?
20160401 21:32:50-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160401 21:37:33< celticminstrel> gfgtdf: The std::atomic in loadscreen.hpp is causing a compiler error for zookeeper - something like "can't convert const char* to void*".
20160401 21:37:56< celticminstrel> gfgtdf: So I thought I'd change it to char* and const_cast when assigning, but since that's bad, only do it as an MSVC2013 workaround.
20160401 21:38:57< wedge009> https://en.wikipedia.org/wiki/Visual_C%2B%2B#Common_MSVC_version has a list of _MSC_VER values.
20160401 21:39:38< gfgtdf> celticminstrel: hmm there is abugrepot about this: https://connect.microsoft.com/VisualStudio/feedback/details/809351/error-when-using-atomic-pointer-to-const
20160401 21:40:03< celticminstrel> gfgtdf: And it sounds like it was fixed for MSVC2015, which is why I decided to try the hacky workaround.
20160401 21:40:35< celticminstrel> Huh, I didn't expect Wikipedia to have that kind of list...
20160401 21:43:05-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160401 21:46:57-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160401 21:49:18< gfgtdf> celticminstrel: i just checkes the assempy code and its the same as without atimic (with just plain const char*) although this migth be different on other achitectures.
20160401 21:50:58< celticminstrel> I don't really know, but I feel like it probably doesn't hurt to keep the atomic now that I've put it in there.
20160401 21:51:46< gfgtdf> celticminstrel: y this was amore meant for the msvc12 workaround
20160401 21:52:13< celticminstrel> Yeah, I could do plain const char* for that, possibly.
20160401 21:52:48< celticminstrel> I'm in the middle of removing BOOST_FOREACH, so I'll look at it after that.
20160401 21:55:36-!- NosajIRL [~nos@208.91.185.104] has joined #wesnoth-dev
20160401 22:04:04-!- Appleman1234 [~Appleman1@KD106161142006.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20160401 22:07:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160401 22:23:58-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160401 22:43:16< celticminstrel> 626 cases left. X_X
20160401 22:49:16-!- mjs-de [~mjs-de@p508C8D35.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20160401 22:52:47-!- horrowind [~Icedove@2a02:810a:83c0:1c18:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160401 22:58:57-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 260 seconds]
20160401 22:59:14-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160401 23:00:42-!- Appleman1234 [~Appleman1@KD106161142191.au-net.ne.jp] has joined #wesnoth-dev
20160401 23:12:35< vultraz> celticminstrel: it's an idea
20160401 23:21:55< vultraz> gfgtdf: I think we should update the included vs project to 2013 because A. vc9 is very old and B. anything prior to 2013 might have problems building with c++11.
20160401 23:23:48< vultraz> celticminstrel: what about boost::ref -> std::ref/cref?
20160401 23:24:20< gfgtdf> vultraz: hmm no, at lest not unless you change boost::bind also toa  std::equivalent
20160401 23:24:28< celticminstrel> Yeah, maybe. That sorta goes with function/bind (though also has other uses besides that).
20160401 23:24:42< vultraz> yes
20160401 23:24:53< vultraz> I meant if you change bind and function you can do that too
20160401 23:24:59< vultraz> honestly I'd say just do it
20160401 23:25:07< celticminstrel> Other Boost things that could be moved to std include shared_ptr and regex (assuming regex support is sufficient in 4.7/2013).
20160401 23:25:23< vultraz> using std::placeholder makes it obvious what _1 and such do
20160401 23:25:34< vultraz> when I first looked at the codebase I had no idea what that did
20160401 23:25:52< celticminstrel> vultraz: If you want to do it as a mass find-and-replace type thing once I'm finished with range-for, that's fine with me; I absolutely do not want to use "std::placeholder::_1", but I'd be okay with something like "ph::_1".
20160401 23:26:06< celticminstrel> (For that to work you need "namespace ph = std::placeholders" somewhere in scope.)
20160401 23:26:12< vultraz> can we declare a global namespace alias?
20160401 23:26:21< celticminstrel> Yes, like I just said. :P
20160401 23:26:34< celticminstrel> Wesnoth also does that already with things like Boost.Filesystem.
20160401 23:26:49< gfgtdf> celticminstrel: hmm i dont see the advantages of swtching to std:: and having to write std::placehoder or even ph:: looks liek a disadvantage to me
20160401 23:27:02< celticminstrel> To make it global, I guess you'd just put it somewhere that every inclusion of <functional> will see...
20160401 23:27:21< celticminstrel> gfgtdf: Yeah, I personally would prefer "using namespace std::placeholders" to "namespace ph = std::placeholders".
20160401 23:28:03< celticminstrel> If it's going to be done everywhere, we could wrap <functional> in a header that does nothing but include it and declare the alias/using.
20160401 23:28:46< celticminstrel> I realize that "using namespace" is frowned upon in general, but I also think this is a place where that namespace is just pointless.
20160401 23:29:28< vultraz> global.hpp?
20160401 23:30:07< celticminstrel> vultraz: No. You can't declare this before the namespace exists, and including <functional> in "global.hpp" would be silly.
20160401 23:31:20< vultraz> so I'd have to do it in each file, after including <functional>?
20160401 23:31:52< gfgtdf> celticminstrel: boost also implemented it _1 with "using namespace boost::placeholders;"
20160401 23:32:13< celticminstrel> vultraz: Yes, or wrap that in a custom header.
20160401 23:32:17< gfgtdf> celticminstrel: i think the onyl reason why std:: doesn'T do it is for possible compability issues.
20160401 23:32:26< celticminstrel> I think you can put them in a function too, if you really want.
20160401 23:32:42< celticminstrel> gfgtdf: Well, std would clash with Boost, if nothing else. :P
20160401 23:33:03-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160401 23:35:55-!- irker509 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160401 23:36:33< vultraz> I'll work on this after you're done with BOOST_FOREACH
20160401 23:36:36< vultraz> how's that going?
20160401 23:36:44< celticminstrel> 560 left.
20160401 23:36:53< celticminstrel> I think that's about halfway.
20160401 23:37:05< vultraz> O_O
20160401 23:37:08< vultraz> jesus
20160401 23:37:12< celticminstrel> Maybe I could've regexed this... not sure...
20160401 23:37:47< vultraz> couldn't you just say replace BOOST_FOREACH( with for( and then the next comma with :?
20160401 23:37:53< vultraz> : ? *
20160401 23:37:54< celticminstrel> Possible.
20160401 23:37:56< celticminstrel> ^y
20160401 23:38:06< celticminstrel> That's roughly what I'm doing, anyway.
20160401 23:38:11< vultraz> right
20160401 23:38:15< vultraz> but I mean with regex
20160401 23:39:00-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160401 23:39:54< celticminstrel> While it might've been faster that way, doing it this way does cause me to notice other things.
20160401 23:40:10< celticminstrel> For example, I discovered some probably-dead code in the FormulaAI engine.
20160401 23:40:18< vultraz> still... tedious a'f 
20160401 23:40:23< celticminstrel> Yeah.
20160401 23:41:33< celticminstrel> We have at least four different files called manager.cpp.
20160401 23:41:39< celticminstrel> That seems like a really popular filename.
20160401 23:45:21-!- gfgtdf_ [~chatzilla@x50ab6f7b.dyn.telefonica.de] has joined #wesnoth-dev
20160401 23:47:24< celticminstrel> BTW vultraz, if you're dealing with Boost.Function, there's a header in utils/ that you'll want to do something with. Probably delete, or maybe rename and use as the wrapper  header (though that's basically the same as deleting it).
20160401 23:48:00< vultraz> boost_function_guarded?
20160401 23:48:04< celticminstrel> Yeah.
20160401 23:48:07-!- gfgtdf [~chatzilla@x50ab6f7b.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160401 23:48:16-!- gfgtdf_ is now known as gfgtdf
20160401 23:48:54< vultraz> if I include <functional> in that file with a using namespace std::placeholder, can I then just include that file and use _1?
20160401 23:49:00< celticminstrel> Yes.
20160401 23:49:35< celticminstrel> vultraz: Unrelated question. For bridging Lua and WFL, do you think there's any need for an "eval_formula" function when there's also a "compile_formula" function?
20160401 23:50:20< celticminstrel> "eval_formula(formula, args)" would be equivalent to "compile_formula(formula)(args)".
20160401 23:52:20< vultraz> eval seems more obvious as to function
20160401 23:52:43 * celticminstrel intends to add compile_formula regardless, the question is really whether to have both or just the one.
20160401 23:53:46< celticminstrel> (Also, from the C++ side, I need eval_formula anyway to use as the call metafunction for a compiled formula.)
20160401 23:53:55< celticminstrel> (So it's no extra effort to add it to the Lua API.)
20160401 23:55:09< gfgtdf> celticminstrel, vultraz: im seeing versiosn numbers liek 1.20000.0 in the addon manger
20160401 23:55:22< gfgtdf> celticminstrel, vultraz: i think this is a bug in wesnoth 1.13+dev
20160401 23:55:25 * vultraz curses
20160401 23:55:29< vultraz> probably to_string again
20160401 23:55:35< celticminstrel> ...is that the GUI2 addon manager?
20160401 23:56:00< celticminstrel> If that's caused by to_string, then your problem is that the versions are stored as numbers. Versions are not numbers.
20160401 23:56:24< gfgtdf> celticminstrel: i dont whether its gui2
20160401 23:56:35< celticminstrel> gfgtdf: Fullscreen?
20160401 23:56:48< gfgtdf> celticminstrel: its not fullscreen.
20160401 23:56:53< celticminstrel> Then GUI1.
20160401 23:56:54< vultraz> then gui1
--- Log closed Sat Apr 02 00:00:10 2016