--- Log opened Wed Mar 30 00:00:34 2016
--- Day changed Wed Mar 30 2016
20160330 00:00:34< vultraz> nope, doesn't work
20160330 00:00:44< vultraz> guess I would manually have to close the dialog
20160330 00:00:54< celticminstrel> It should work.
20160330 00:00:54< vultraz> I don't understand, though, why did it work before
20160330 00:01:09< vultraz> and why don't the cursors work :|
20160330 00:01:57< celticminstrel> You could manually close the dialog if you prefer that, of course, but I think using scope is the better option.
20160330 00:02:20< celticminstrel> Also, I think I know why the cursors don't work.
20160330 00:02:50< celticminstrel> You're using cursor::setter, which sets the cursor for the duration of a scope, but the scope is exited immediately after you set it.
20160330 00:03:08< celticminstrel> Use cursor::set instead (or whatever do_game_loop was already using).
20160330 00:03:24< celticminstrel> Or...
20160330 00:03:33< celticminstrel> Declare a cursor::setter as a member of the loadscreen class.
20160330 00:03:48< celticminstrel> (But that requires you rely on scope to destroy the loadscreen.)
20160330 00:13:09-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160330 00:23:12< celticminstrel> An empty filter matches all units, doesn't it?
20160330 00:23:40< celticminstrel> Oh, wait, hmm... I'm doing {"and", nil} here, that's probably not good...
20160330 00:25:26-!- nos_ [~nos@208.91.185.104] has joined #wesnoth-dev
20160330 00:26:29-!- nos_ is now known as NosajIRL
20160330 00:31:46< celticminstrel> vultraz: Any progress?
20160330 00:36:40< vultraz> no I give up
20160330 00:36:54< celticminstrel> Then I'll give it a shot (unless gfgtdf wants to).
20160330 00:38:23< celticminstrel> I wonder if some wesnoth.allow_interact() type function should be added.
20160330 00:43:16< celticminstrel> I broke Wesnoth by trying to open the Lua console after printing around 10,000 lines to it.
20160330 00:44:09< vultraz> hmmm
20160330 00:44:20< vultraz> ok so when using display() and cursor::set()
20160330 00:44:32< vultraz> the cursor turns to WAIT for a second
20160330 00:44:36< vultraz> then back to NORMAL
20160330 00:44:48< vultraz> probably confirms that the dialog is indeed being destroyed early
20160330 00:45:04< celticminstrel> Yes, probably.
20160330 00:45:17< celticminstrel> Are you going to deal with this after all? Should I not give it a shot?
20160330 00:45:26< vultraz> no, no, you give it a shot
20160330 00:45:29< vultraz> I'm tired
20160330 00:45:32< celticminstrel> Okay.
20160330 00:45:43< vultraz> need to get lunch..
20160330 00:45:47< celticminstrel> I'll remember to try visiting the editor.
20160330 00:46:08< vultraz> this will need to be fixed if we want an updating loadscreen
20160330 00:50:31< celticminstrel> Hmm, maybe adding a console table would be useful...
20160330 00:50:49< celticminstrel> console.print(), console.clear(), console.open()
20160330 00:50:59< celticminstrel> The first would point to ilua._pretty_print()
20160330 00:51:09< celticminstrel> (Thus distinguishing it from plain print())
20160330 00:58:27-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160330 01:01:39-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20160330 01:01:39-!- wedge010 is now known as wedge009
20160330 01:14:50-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 01:31:34-!- gfgtdf_ [~chatzilla@f054057118.adsl.alicedsl.de] has joined #wesnoth-dev
20160330 01:33:44-!- gfgtdf [~chatzilla@f054048082.adsl.alicedsl.de] has quit [Ping timeout: 260 seconds]
20160330 01:33:59-!- gfgtdf_ is now known as gfgtdf
20160330 01:41:29< ancestral> Anyone having issues ending a turn in latest master?
20160330 01:41:32< ancestral> I get this: Assertion failed: (px != 0), function operator*, file Headers/boost/smart_ptr/shared_ptr.hpp, line 646.
20160330 01:44:55< vultraz> You don't have latest master, then
20160330 01:46:15< ancestral> Building no
20160330 01:46:17< ancestral> now
20160330 01:47:17< ancestral> Okay
20160330 01:47:22< ancestral> Not crashing
20160330 01:48:01-!- irker962 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160330 01:54:53< ancestral> Sooooo
20160330 01:54:57< ancestral> Wesnoth loads faster now
20160330 01:55:19< ancestral> vultraz: If that was because of the lack of a progress bar, then I am in the anti-progress bar camp
20160330 02:00:01< gfgtdf> hmm guess what happened when i tried to implement the multithreaded version of the loadingscreen
20160330 02:00:17< celticminstrel> Hm?
20160330 02:00:29< celticminstrel> Something good? Something bad? What happened?
20160330 02:01:02< gfgtdf> celticminstrel: hmm i got 2 assertion failues, one in each thread.
20160330 02:01:12< ancestral> celticminstrel: Wesnoth seems to load faster
20160330 02:01:19< celticminstrel> ancestral: I've noticed.
20160330 02:01:21< ancestral> But I haven’t done any official testing
20160330 02:01:26< celticminstrel> gfgtdf: Uhh. Okay?
20160330 02:01:36< vultraz> ancestral: it certainly does
20160330 02:01:57< vultraz> ancestral: what do you think of the new design? (barring comments about the progress bar)
20160330 02:02:01< ancestral> (Perceptively, which leads me to believe it must, as typically loading bars usually are reported by users to think something is working faster)
20160330 02:02:23< ancestral> vultraz: Good, although
20160330 02:02:50< ancestral> Would any kind of subtle animation slow the game down?
20160330 02:03:01< vultraz> No
20160330 02:03:06< ancestral> Like, if there were diamonds that added to the sides
20160330 02:03:07< gfgtdf> surprisingly i got both from inside pango/cairo
20160330 02:03:08< vultraz> Just that we currently can't draw an animation :P
20160330 02:03:21< ancestral> Can we draw a new image during the loading screen?
20160330 02:03:49< vultraz> well
20160330 02:03:51< vultraz> yes
20160330 02:03:53< vultraz> but...
20160330 02:04:04< vultraz> any animation should be constant 
20160330 02:04:12< vultraz> the loadscreen is up for a few seconds max
20160330 02:04:22< vultraz> we don't want to extend the time simply to handle an animation
20160330 02:04:29< vultraz> so it should always play for the duration of the dialog
20160330 02:04:39< vultraz> it's something we'd need to implement
20160330 02:05:52< ancestral> Yeah
20160330 02:17:47< gfgtdf> anyone knows what "ERROR: type error:  expected string but found null ((null))" means ?
20160330 02:18:15< celticminstrel> Sounds like a formula error.
20160330 02:20:11< vultraz> ah!
20160330 02:20:15< vultraz> no that's not a formula error
20160330 02:20:23< vultraz> or maybe it is, but
20160330 02:20:56< vultraz> it's the same error you get with this bug https://gna.org/bugs/index.php?22028
20160330 02:21:18< gfgtdf> somehow after i fixed the assertion failures the game now immidiateley closes itslef after startup and i get that error in stderr
20160330 02:21:36< vultraz> gfgtdf: see bug above
20160330 02:22:54< celticminstrel> Yes, definitely a formula error.
20160330 02:26:25< gfgtdf> this is the stacktrace from the error: http://pastebin.com/GavM06jd
20160330 02:39:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 02:44:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160330 02:46:24< gfgtdf> celticminstrel: here my first non-crashing attempt for the loadingscreen: https://github.com/gfgtdf/wesnoth-old/commit/168f5c9f824e9e7bf8f927501ec5bbb1e14c969a
20160330 02:48:27< gfgtdf> celticminstrel: i also think this is useful when tying to implement animations.
20160330 02:48:37< ancestral> vultraz: Instead of an image, what about changing text?
20160330 02:49:22< ancestral> ◇ Loading ◇
20160330 02:49:25< ancestral> ◇◇ Loading ◇◇
20160330 02:49:31< ancestral> ◇◇◇ Loading ◇◇◇
20160330 02:50:39< ancestral> Or fading text
20160330 02:50:51< celticminstrel> I don't think I like the fading idea.
20160330 02:50:58< ancestral> There needs to be some kind of visual cue
20160330 02:51:03< celticminstrel> Yes.
20160330 02:51:07< ancestral> s/fading/pulsing
20160330 02:51:21< celticminstrel> I dislike pulsing too, because that's a looped effect.
20160330 02:51:33< ancestral> I don’t think looping is bad
20160330 02:51:45< celticminstrel> I don't think looping is good, but it's better than nothing.
20160330 02:51:48< ancestral> It’s all about the user knowing the game isn’t frozen
20160330 02:52:01< celticminstrel> That's why it's better than nothing.
20160330 02:54:23-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 02:54:24< travis-ci> gfgtdf/wesnoth-old#621 (master - 168f5c9 : gfgtdf): The build failed.
20160330 02:54:24< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/119423589
20160330 02:54:24-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 02:55:49< celticminstrel> My work is going to totally conflict with gfgtdf's...
20160330 02:56:21< gfgtdf> celticminstrel: what yre you trying to do ?
20160330 02:56:27< celticminstrel> I think that's a weird thing to be using a lambda for...
20160330 02:56:34< celticminstrel> I was abolishing the display() method.
20160330 02:56:50< gfgtdf> celticminstrel: hmm why?
20160330 02:57:03< celticminstrel> And I was trying to fix the issue with the incorrect cursor.
20160330 02:57:16-!- SigurdFD [~SigurdFD@dynamic-acs-72-23-176-151.zoominternet.net] has joined #wesnoth-dev
20160330 02:57:25< celticminstrel> Because you noted that it's immediately destroying the dialog.
20160330 02:58:38< celticminstrel> And I prefer the idea of an RAII-based loadscreen.
20160330 02:59:10< gfgtdf> celticminstrel: well my loadsceen also is raii based
20160330 02:59:28< celticminstrel> Eh? It doesn't look like it from here...
20160330 02:59:37< gfgtdf> celticminstrel: actuall i think the mian problem with vultraz cursor is that he again used temprarires of cursor::setter
20160330 03:00:00< vultraz> gfgtdf: even if I use cursor::set it reverts in about a second
20160330 03:00:01< celticminstrel> Yeah, but I'm still having the issue even after I put a cursor::setter in the loadscreen class.
20160330 03:00:13< ancestral> Frustrating
20160330 03:00:27< ancestral> I don’t know how to tell GUI1 to ignore system fonts
20160330 03:00:29< celticminstrel> Maybe something else is setting the cursor. I should put a breakpoint in cursor::set.
20160330 03:00:30< ancestral> Unless
20160330 03:00:40< ancestral> No, that would be bad
20160330 03:00:48< celticminstrel> ancestral: You could always just change GUI1 to draw with ttext... >_>
20160330 03:00:55< ancestral> vultraz: Trouble is, condensed versions are getting chosen if you have the font installed in your system
20160330 03:01:12< ancestral> The only way around this that I can think of
20160330 03:01:23< ancestral> Is renaming the font installed in the fonts directory
20160330 03:01:28< ancestral> So it doesn’t conflict
20160330 03:01:41< ancestral> i.e. dejavusans-wesnoth.ttf
20160330 03:01:50< vultraz> huh
20160330 03:01:52< celticminstrel> Hmm, I see why gfgtdf is using lambdas - you're delegating the load work to an auxiliary thread, right?
20160330 03:01:55< ancestral> And more importantly, the name
20160330 03:02:12< celticminstrel> (BTW, I think I'd recommend [&] instead of [=] unless you have a good reason not to want references.)
20160330 03:02:15< ancestral> (the filename matters none)
20160330 03:02:34< celticminstrel> (Using [=] means that every local variable in scope gets copied into the lambda's closure.)
20160330 03:03:05< ancestral> C++11 voodoo?
20160330 03:03:11< celticminstrel> Yes.
20160330 03:03:31< celticminstrel> Is it okay if I set the XCode project to compile as C++11 now?
20160330 03:03:56< gfgtdf> celticminstrel: well i may be changing it to bind, i mainly used teh lambdas to write it faster
20160330 03:04:20< vultraz> gfgtdf: if you can build with lambdas you can use them
20160330 03:04:32< celticminstrel> gfgtdf: I think lambdas are okay in this case.
20160330 03:04:34< ancestral> celticminstrel: Probably?
20160330 03:04:46< celticminstrel> It seems a little weird to me, but I think it's fine to keep using them.
20160330 03:04:56< celticminstrel> ancestral: Why only probably? :P
20160330 03:05:06< ancestral> I don’t know, that’s why ;-)
20160330 03:05:38< celticminstrel> Well, I'm sure you and mattsc won't have any problems with C++11 stuff; if anything, we'll be limited by myself and maybe zookeeper now.
20160330 03:06:15< celticminstrel> (Assuming zookeeper is using 2013)
20160330 03:06:17< gfgtdf> vultraz: i updated to msvc 2015 now. Its unlikeley that i'll change back to msvc 2010.
20160330 03:06:28< vultraz> gfgtdf: ahh, good
20160330 03:06:31< vultraz> gfgtdf: then use c++11 :D
20160330 03:07:11< celticminstrel> Should I do a few C++11 quick-fixes throughout the code? For example, nullptr.
20160330 03:07:20< vultraz> celticminstrel: you can remove the #ifdef CXX11 blocks now
20160330 03:07:30< celticminstrel> Maybe range-for, not sure on that one.
20160330 03:07:39< celticminstrel> What else...
20160330 03:08:00< celticminstrel> (I'll hold off on my loadscreen work, since gfgtdf is moving in a different direction which may be better.)
20160330 03:08:08< vultraz> celticminstrel: lexical_cast<std::string> and str_cast -> std::to_string()
20160330 03:08:40< celticminstrel> Ehh, not sure I want to bother on that... but I'll think about it.
20160330 03:08:48< vultraz> I can do it
20160330 03:08:51< gfgtdf> vultraz: are there advantages of td::to_string ?
20160330 03:08:53< celticminstrel> Oh right, I was thinking maybe a few Boost->std substitutions.
20160330 03:09:23< vultraz> gfgtdf: it's better to use standard library implementations 
20160330 03:09:32< vultraz> celticminstrel: I can do it
20160330 03:09:42< celticminstrel> I recall MinGW not having std::thread as recently as a few months ago, so we should probably stick to Boost.Thread though.
20160330 03:09:49< vultraz> celticminstrel: and we need to update the projectfiles
20160330 03:09:50< vultraz> and travis
20160330 03:09:59< celticminstrel> Travis should be easy.
20160330 03:14:20< gfgtdf> i also don't have expression sfinae and some other things.
20160330 03:14:55< celticminstrel> Not entirely sure, but I suspect expression SFINAE won't be something we need.
20160330 03:15:24< ancestral> vultraz: I’m struggling to figure out how to change the GUI1 text size
20160330 03:15:34< ancestral> outside of theme/default.cfg
20160330 03:15:37< ancestral> Is there another spot?
20160330 03:15:45< ancestral> Wait, in gui?
20160330 03:16:08-!- gfgtdf [~chatzilla@f054057118.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160315153207]]
20160330 03:16:58< ancestral> For example, the text in the Multiplayer dialog
20160330 03:17:12< vultraz> ancestral: gui/ is gui2
20160330 03:17:22< ancestral> So where else then?
20160330 03:17:35< vultraz> ancestral: font.hpp:60
20160330 03:17:41< ancestral> theme/_initial.cfg?
20160330 03:17:55< ancestral> Hardcoded? yuck
20160330 03:18:17< celticminstrel> My final tests in the Fast MAI have get_attacks() at 0.0505|0.0025|0.042, original method at 0.0265|0.0275|0.027, new method at 0.0425|0.0435|0.041.
20160330 03:19:27< mattsc> Well, so the original method seems definitely faster.
20160330 03:19:29< vultraz> ancestral: gui1 is very hardcoded
20160330 03:19:39< mattsc> However, if this is only called once per move, it doesn’t matter for this AI.
20160330 03:19:46< mattsc> It might matter in other cases.
20160330 03:19:52< mattsc> I don’t know …
20160330 03:19:58< vultraz> ancestral: if we make gui1 use ttext like celticminstrel suggested we can probably drop sdl_ttf and the hardcoded stuff
20160330 03:20:27< celticminstrel> mattsc: Well, the Fast MAI already caches the list of movable units, so I think that does mean it'll only be once per move.
20160330 03:21:15< celticminstrel> Or twice per move, if you assume the leader combat CA is called exactly once (the leader combat CA doesn't cache anything).
20160330 03:21:16< mattsc> celticminstrel: that’s quite possible (I just don’t remember off the top of my head and cannot look at it right now)
20160330 03:21:44< mattsc> For my MP AIs this difference would defintiely matter though.
20160330 03:21:52< mattsc> *some of my MP AIs
20160330 03:22:35< celticminstrel> Oh, right, I suppose it'll be called once per move for the side's units, but maybe more than once for enemy units...?
20160330 03:23:09< celticminstrel> I'm going to test once more to make sure there isn't a noticable lag before the AI's every attack.
20160330 03:23:15< celticminstrel> Then I'll commit and move on to other things.
20160330 03:23:19< mattsc> For example.
20160330 03:23:31< mattsc> Sounds good.
20160330 03:37:23-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 03:40:24< celticminstrel> So, it seems that with all my testing for when there's an attacks aspect, I broke the case where there isn't one.
20160330 03:44:01-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 03:45:35< ancestral> Hmm
20160330 03:46:55< celticminstrel> It may be a little slower than before (not enough that I can tell in the test scenario though), but it's still significant;y faster than the default AI.
20160330 03:53:16< mattsc> great
20160330 03:53:20< celticminstrel> ^significantly
20160330 03:58:48< celticminstrel> Okay vultraz, so about C++11; I'll do nullptr and possibly range-for, and the #ifdef blocks; you'll do std::to_string; is there anything else we should do right away?
20160330 03:59:52< Aginor> announce it on the mailing list.
20160330 03:59:58< celticminstrel> Good point.
20160330 04:00:06< celticminstrel> Who'll do that?
20160330 04:00:16< Aginor> whoever is pushing for it
20160330 04:00:24< celticminstrel> So either me or vultraz.
20160330 04:01:36< celticminstrel> Can you handle that, vultraz?
20160330 04:03:39< Aginor> I also think you should make sure there's a grace period for people to respond before you start making changes to the codebase
20160330 04:03:50< Aginor> you also need to update scons and cmake
20160330 04:04:17< celticminstrel> I've updated .travis.yml, but I may not start actual code changes tonight.
20160330 04:04:30< celticminstrel> I have a few other things to take care of first.
20160330 04:04:55< celticminstrel> I'm not really sure how I would have to update scons and CMake, either...
20160330 04:06:59< Aginor> they contain compiler checks for features
20160330 04:07:06< Aginor> enable/disable flags based on them
20160330 04:07:20< Aginor> you may wish to make sure they pick the right standard
20160330 04:07:41< celticminstrel> C++11 means dropping support for OSX 10.6.
20160330 04:10:59< Aginor> has this been discussed with the affected parties?
20160330 04:11:21< celticminstrel> As far as I'm aware, the affected parties are gfgtdf.
20160330 04:11:41< celticminstrel> At least among devs.
20160330 04:12:20< Aginor> some features are also not available in debian oldstable
20160330 04:13:06< vultraz> we've already discussed this change before
20160330 04:14:21< celticminstrel> vultraz: Are you up for announcing it on the mailing list?
20160330 04:16:44< celticminstrel> vultraz: Also, as I asked, is there anything else to be done quickly??
20160330 04:19:17< celticminstrel> So, it turns out the Boost libs from Mac Compile Stuff are not compatible with libc++/clang.
20160330 04:20:01< celticminstrel> ancestral: Since you need to update those libs anyway, do you think it's okay to move to libc++? (Also, do you think it's okay to drop support for OSX 10.6?)
20160330 04:20:12< celticminstrel> mattsc: ^ If you have opinions too, please say.
20160330 04:20:24< ancestral> Hmm
20160330 04:20:50< ancestral> What does moving to libc++ entail?
20160330 04:21:28< celticminstrel> Well, for me, my libstdc++ (which is what it's currently building against) is rather outdated and lacks a lot of the C++11 library support.
20160330 04:21:48< celticminstrel> I'm not entirely sure what the libstdc++ situation is in newer OSX.
20160330 04:21:58< celticminstrel> It might've even been removed, for all I know.
20160330 04:22:13< celticminstrel> Anyway, libc++ does have most (if not all) of the C++11 standard library support.
20160330 04:22:14< Aginor> maybe we should explore these things before we switch to c++11?
20160330 04:23:50< celticminstrel> For you two on your newer computers I assume it has all the C++11 library support.
20160330 04:25:28< mattsc> celticminstrel: sorry, no experience with and therefore no opinion on it.
20160330 04:26:26< celticminstrel> ancestral: The last time I tried (maybe a year ago?), building Boost for libc++ required some extra effort.
20160330 04:28:01< celticminstrel> So, moving to libc++ would entail ensuring that the Boost in MacCompileStuff is a libc++-compatible variant, which may or may not still entail passing undocumented flags to the Boost build system (to force use of clang and libc++ linkage).
20160330 04:28:03< ancestral> I guess my question is better rephrased as, “what does this mean for 10.6 users?”
20160330 04:28:12< ancestral> I mean
20160330 04:28:17< ancestral> Why are they left out?
20160330 04:28:46< celticminstrel> Ah, I'm not sure exactly, but XCode complained when I tried building with libc++, because Wesnoth was set to deploy for 10.6.
20160330 04:29:03< celticminstrel> Maybe 10.6 doesn't ship with it or something.
20160330 04:31:41< celticminstrel> Updating the XCode project to libc++ does also mean that your builds will likely both break until you've replaced your Boost libs, so I suppose I'll wait a bit before actually doing this...
20160330 04:35:49< celticminstrel> I let the Fast MAI test scenario play in the background, and the default AI is winning. I guess this shouldn't be a surprise though.
20160330 04:36:15< mattsc> Nope.  Read the comments on the wiki page.  ;)
20160330 04:38:47< vultraz> celticminstrel: sure, but I wouldn't be technical
20160330 04:39:17< celticminstrel> Hmm, do we need to be technical? Aginor?
20160330 04:40:50< vultraz> honestly, I don't even see why we need to
20160330 04:41:00< vultraz> the only people who care are in this channel
20160330 04:41:10< celticminstrel> You might be surprised.
20160330 04:42:31< vultraz> Let me rephrase that: the only active developers are here 
20160330 04:42:50< celticminstrel> I think the point is that devs aren't the only people who need to know.
20160330 04:43:03< vultraz> Why?
20160330 04:43:08< vultraz> Just curious
20160330 04:43:20< vultraz> Plus the thing is called wesnoth-dev 
20160330 04:43:23< celticminstrel> People who build packages for Linux distributions may need to know, for example.
20160330 04:43:24< vultraz> only devs read it :P
20160330 04:43:39< celticminstrel> I dunno about that.
20160330 04:43:41< vultraz> That's a different ml, I believe
20160330 04:44:03< celticminstrel> Then, maybe it should be announced on that mailing list. I dunno...
20160330 04:45:37< vultraz> I think the first thing you should commit is dropping pre- c++11 builds from travis
20160330 04:45:49< celticminstrel> Already done.
20160330 04:45:52< celticminstrel> Will push soon.
20160330 04:46:09< celticminstrel> Actually, I could probably push now.
20160330 04:47:20< celticminstrel> Oh right. Maybe not.
20160330 04:47:24-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has quit [Ping timeout: 246 seconds]
20160330 04:51:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 04:52:08< vultraz> wow, LOT of cases of lexical_cast<std::string> and str_cast
20160330 04:52:19< vultraz> thankfully I can do a simple find/replace
20160330 04:52:29-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 04:52:30< vultraz> I'll wait until you commit the travis thing
20160330 04:52:57< celticminstrel> vultraz: Don't forget that there's lexical_cast and also boost::lexical_cast, and the former is in a header somewhere in the Wesnoth source... IIRC.
20160330 04:53:07< vultraz> yes
20160330 04:53:13-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 04:53:55< vultraz> ancestral: I've been using Lato for the past few days, BTW. It seems pretty acceptable with the font sizes you provided.
20160330 04:54:39< ancestral> vultraz: Yeah, I think it’s the best option
20160330 04:54:54< vultraz> I'll leave you to deal with the implementation
20160330 04:54:56< ancestral> I would say 13/15/17/20/22 works best for me, plus
20160330 04:55:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160330 04:55:45< ancestral> data/gui/macros/_initial.cfg:32 change vertical center alignment
20160330 04:56:14< ancestral>   "(if(text_height < height, (height - text_height - 1) / 2, 0))"
20160330 04:56:39< vultraz> I've been using / 3
20160330 04:57:00< ancestral> You know where the /2 comes from, right?
20160330 04:57:09< vultraz> no idea
20160330 04:57:18< vultraz> guess since it wants to be in the middle?
20160330 04:57:19< ancestral> Okay, so you have a box
20160330 04:57:21< ancestral> Yes
20160330 04:58:27< ancestral> vultraz: Anyway, the only thing I need to figure out is how best to increase the GUI1 sizes
20160330 04:58:35< ancestral> Or, leave GUI1 with DVS for now
20160330 04:58:45< vultraz> I gave you the file..
20160330 04:58:49< ancestral> font.hpp has hardcoded values
20160330 04:58:58< ancestral> But it’s expecting certain sizes there
20160330 04:59:08< celticminstrel> Or move GUI1 to ttext.
20160330 04:59:16< ancestral> So okay, let’s say I increase those
20160330 04:59:20< ancestral> (which I tried)
20160330 04:59:34< ancestral> But it appears there are STILL other places with hardcodedness
20160330 04:59:42< vultraz> oh good god :|
20160330 04:59:42< ancestral> Buttons in the multiplayer dialog for example
20160330 04:59:52< ancestral> Seemed unaffected, or
20160330 05:00:16< ancestral> Maybe I didn’t bump the values high enough? I took the same NORMAL/SMALL/TINY values
20160330 05:00:26< ancestral> celticminstrel: Sounds better more and more
20160330 05:00:58< celticminstrel> What the heck is going on in this FAI recruitment... :|
20160330 05:01:32< vultraz> ancestral: if we switch gui1 to ttext, let's take it in stages 
20160330 05:02:04< ancestral> So I would suggest a few different things
20160330 05:02:08< vultraz> first, commit Lato and make GUI2 use it, with new font values, leaving GUI1 with DVS 
20160330 05:02:18< vultraz> then move GUI1 to ttext and by extension, Lato
20160330 05:02:24< ancestral> That would be my first suggestion
20160330 05:02:29< ancestral> The other would be the reverse
20160330 05:03:10< vultraz> I'd say it's better to get the new font in
20160330 05:03:19< vultraz> since we're gradually chipping away at gui1
20160330 05:03:49< ancestral> Alright, I’ll fork and put the changes it
20160330 05:03:51< ancestral> *in
20160330 05:04:39< ancestral> (I think Lato is > Carlito as it is getting regular updates, and that will likely benefit us in the long run)
20160330 05:04:47< vultraz> Yeah, seems reasonable
20160330 05:05:03-!- irker535 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160330 05:05:03< irker535> wesnoth: Celtic Minstrel wesnoth:master 85a498ba159a / data/ai/micro_ais/cas/ (ca_fast_attack_utils.lua ca_fast_combat.lua ca_fast_combat_leader.lua): Fast MAI: Correctly honour the attacks aspect if set https://github.com/wesnoth/wesnoth/commit/85a498ba159a7cf586369d8a64ce07755d87d8e9
20160330 05:05:05< irker535> wesnoth: Celtic Minstrel wesnoth:master 74ce7454d982 / data/ai/micro_ais/scenarios/recruiting.cfg: Random Recruit MAI test: Add second [probability] tag https://github.com/wesnoth/wesnoth/commit/74ce7454d98210894a9f83950f3fe608cfd8125c
20160330 05:05:07< irker535> wesnoth: Celtic Minstrel wesnoth:master d7c58276c2cb / .travis.yml: Travis: Make all builds C++11 https://github.com/wesnoth/wesnoth/commit/d7c58276c2cba60c1b15d7be7c2ffae8f2aae7a2
20160330 05:05:12< ancestral> I did try the other typefaces, and I’m in agreement. The others fare worse
20160330 05:06:06< celticminstrel> Let's see if that also fixes the Travis build...
20160330 05:06:22< celticminstrel> vultraz: I suggest holding back a day or two longer on the C++11 fixes.
20160330 05:06:28< vultraz> why?
20160330 05:06:30< celticminstrel> Not fixes, but you know what I mean.
20160330 05:06:31< vultraz> I mean
20160330 05:06:33< vultraz> what for?
20160330 05:06:55-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160330 05:06:56< celticminstrel> Make sure everyone is ready for it - Mac users in particular will may need to switch Boost versions.
20160330 05:07:33< celticminstrel> ^-will oe -may
20160330 05:07:35< celticminstrel> ^or
20160330 05:07:42< vultraz> Bump, or recompile?
20160330 05:08:11< celticminstrel> Potentially recompile, depending on Boost's default configuration.
20160330 05:08:20< ancestral> Is <story> GUI1?
20160330 05:08:26< vultraz> yes
20160330 05:08:37< vultraz> if you mean the storytext
20160330 05:08:41< celticminstrel> I personally shouldn't need to since I've been using libc++ Boost libs for awhile now (in other projects), but I'm not sure about otehrs.
20160330 05:08:44< celticminstrel> ^others
20160330 05:08:57< celticminstrel> ancestral: It's GUI1, but uses ttext.
20160330 05:19:35< vultraz> celticminstrel: might be worth updating so people then need to update
20160330 05:23:03< vultraz> celticminstrel: but I'll defer to you if you think I should wait
20160330 05:23:15< celticminstrel> Just a day or two.
20160330 05:32:04-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160330 05:32:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160330 05:36:07-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 05:36:08< travis-ci> wesnoth/wesnoth#9100 (master - d7c5827 : Celtic Minstrel): The build has errored.
20160330 05:36:08< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119439346
20160330 05:36:08-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 05:39:22< celticminstrel> I think I suddenly realized why the FAI recruitment broke.
20160330 05:39:38< celticminstrel> I changed unit_callable but not unit_type_callable.
20160330 05:39:47< celticminstrel> And the Travis build is totally broken now. Hmm.
20160330 05:40:57< celticminstrel> Oh, never mind. I guess it's a unit tests failure. vultraz probably forgot to add the loadscreen or something.
20160330 05:41:26< celticminstrel> Why is there a warning in the unit tests output about deprecated difficulty_descriptions?
20160330 05:41:33< vultraz> no idea
20160330 05:46:14-!- SigurdFD [~SigurdFD@dynamic-acs-72-23-176-151.zoominternet.net] has quit []
20160330 06:14:22-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160330 06:21:11< celticminstrel> FAI recruitment now works again. There is however one error in it still.
20160330 06:22:26< celticminstrel> (I assume that error existed before, too.)
20160330 06:26:05< celticminstrel> Doesn't seem like it's an error that actually matters. More of a warning.
20160330 06:36:47< irker535> wesnoth: Celtic Minstrel wesnoth:master 64892b8c81c3 / / (4 files in 3 dirs): Align formula and Lua views of unit types https://github.com/wesnoth/wesnoth/commit/64892b8c81c3da7af87c820508c6cef9cf98adf5
20160330 06:36:49< irker535> wesnoth: Celtic Minstrel wesnoth:master de270e4d1d25 / data/campaigns/Legend_of_Wesmere/ (ai/patrol.fai scenarios/chapter4/16_The_Chief_Must_Die.cfg): Remove duplicate file https://github.com/wesnoth/wesnoth/commit/de270e4d1d25d35f9668afffeb8c1b9ff3804d0d
20160330 06:48:32< irker535> wesnoth: ancestral wesnoth:ancestral-lato 353a9c38e789 / data/ (gui/macros/_initial.cfg hardwired/fonts.cfg): Lato is now the new game font. Initially, this will be limited to GUI2, but as t https://github.com/wesnoth/wesnoth/commit/353a9c38e7893bafbd166153ef216482d34aa895
20160330 06:49:45< ancestral> Wait a sec, I should be in my own branch
20160330 06:50:33< ancestral> Okay, I am
20160330 06:53:17< vultraz> ancestral: so how is this going to work?
20160330 06:53:32< ancestral> Making a pull request
20160330 06:53:37< ancestral> But you can pop in my branch
20160330 06:53:58< ancestral> Ooh, gotta check one thing
20160330 06:54:05< vultraz> ancestral: shouldn't you actually commit the font files first..? :P
20160330 06:54:18< ancestral> They should be there?
20160330 06:54:24< ancestral> Maybe not
20160330 06:54:46< vultraz> you only committed the code changes, but didn't send the actual files :P
20160330 06:54:55< ancestral> Yeah, that would be a problem.
20160330 06:55:10< celticminstrel> You also made a PR which looked reasonable.
20160330 06:55:37< celticminstrel> Reasonable in that it seemed the font files were committed.
20160330 06:56:01< vultraz> ah, now I see them
20160330 06:56:28< celticminstrel> BTW, does Lato have a monospace version?
20160330 06:57:25-!- celticminstrel is now known as celmin|sleep
20160330 06:58:26< vultraz> Don't think so, actually...
20160330 07:02:18-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160330 07:02:39< irker535> wesnoth: ancestral wesnoth:ancestral-lato 280c5fe69a2d / / (5 files in 2 dirs): Minor formatting change to _initial.cfg https://github.com/wesnoth/wesnoth/commit/280c5fe69a2d1b4a2039c8f1bd6a70f1de7b21a4
20160330 07:03:20< vultraz> should probably squash those commits for the PR
20160330 07:11:06-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 07:11:07< travis-ci> wesnoth/wesnoth#9101 (master - de270e4 : Celtic Minstrel): The build has errored.
20160330 07:11:07< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119449885
20160330 07:11:07-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 07:18:39< ancestral> Okay
20160330 07:18:49< ancestral> vultraz: Yeah it doesn’t
20160330 07:19:37< vultraz> I wonder what font I'm seeing when I look at places that used monospace, then
20160330 07:20:06< ancestral> Where would this be?
20160330 07:20:15< ancestral> Where is monospace used
20160330 07:20:18< vultraz> gamestate inspector
20160330 07:20:20< vultraz> and lua console
20160330 07:20:23< vultraz> formula debugger
20160330 07:20:28< vultraz> first two are easiest to get to
20160330 07:21:09< vultraz> it is a monospace font I'm seeing
20160330 07:21:23< ancestral> Oh
20160330 07:21:33< ancestral> Just realized
20160330 07:21:42< ancestral> I have to make a change
20160330 07:23:52< irker535> wesnoth: Martin Proud wesnoth:ancestral-lato 30fefe488af1 / data/hardwired/fonts.cfg: Leaving Lato-Regular.ttf out due to GUI1 reasons https://github.com/wesnoth/wesnoth/commit/30fefe488af148d0347010fcb87268680fea6db1
20160330 07:26:09< vultraz> ancestral: I wonder if we should also ship a serif font or a 'fancy' font along with this, for cases where umc might want a 'script' font
20160330 07:26:17-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 07:27:31-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 07:27:37< vultraz> ancestral: since it is possible to use pango to specify that you want a serif font
20160330 07:27:41< ancestral> vultraz: If you want my opinion, I think let the umc authors supply their own fonts
20160330 07:27:48< vultraz> that's not possible
20160330 07:27:53< ancestral> Currently
20160330 07:28:28< vultraz> It's not really a problem
20160330 07:28:30< ancestral> But the fonts can be loaded from anywhere, right?
20160330 07:28:35< vultraz> I guess
20160330 07:28:47< vultraz> using font_family='serif' in pango markup gives you the system default serif font
20160330 07:28:50< vultraz> which doesn't always look good :/
20160330 07:28:50< ancestral> Obviously, it would require a lot of work
20160330 07:28:59< ancestral> My second choice?
20160330 07:29:01< ancestral> Deja Vu Serif
20160330 07:29:14< ancestral> Only because it’s a companion to DVS
20160330 07:30:51< ancestral> vultraz: Long term? Find something nice. Kinda like https://www.wesnoth.org/start/1.12/index.en.html
20160330 07:31:17-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 07:31:18< travis-ci> wesnoth/wesnoth#9102 (ancestral-lato - de270e4 : Celtic Minstrel): The build has errored.
20160330 07:31:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119450442
20160330 07:31:18-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 07:32:09< ancestral> vultraz: Food for thought: https://www.typewolf.com/site-of-the-day/fonts/lato
20160330 07:33:26< ancestral> Hmm
20160330 07:33:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 07:34:32< ancestral> I think my PR won’t work exactly as designed. No one will see the fonts unless they install Lato
20160330 07:34:41< ancestral> But it’s either that, or Lato everywhere
20160330 07:36:28< ancestral> I have the next 6 days off. I could take a stab at fixing the theme to make it play nicely. If so, then I could put Lato back in the font list
20160330 07:38:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20160330 07:39:25< vultraz> ancestral: it should still work for gui2
20160330 07:39:32< vultraz> gui2 only relies on family_order
20160330 07:39:34< vultraz> well
20160330 07:39:35< vultraz> ttext
20160330 07:40:02< ancestral> I think Lato would still need to be installed
20160330 07:40:08< ancestral> in your system
20160330 07:40:17< vultraz> I don't think so
20160330 07:40:20< ancestral> Unless Wesnoth looks in fonts?
20160330 07:40:21< vultraz> I haven't installed it
20160330 07:40:23< ancestral> data/fonts
20160330 07:40:26< ancestral> Hmm
20160330 07:40:33< ancestral> Do you habe 
20160330 07:41:19< ancestral> vultraz: Do you have Lato-Regular.ttf in hardwired/fonts/cfg:7?
20160330 07:41:29< vultraz> yes
20160330 07:41:33< ancestral> Remove that
20160330 07:41:41< ancestral> or
20160330 07:41:55< ancestral> Tell me if GUI1 dialogs are showing Lato (because with it in line 7 they should be)
20160330 07:42:16< vultraz> gui1 dialogs are showing boxes
20160330 07:42:22< vultraz> in place of characters
20160330 07:42:39< ancestral> With Lato-Regular.ttf in line 7 or without?
20160330 07:42:42-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 07:42:43< travis-ci> wesnoth/wesnoth#9103 (ancestral-lato - 353a9c3 : ancestral): The build has errored.
20160330 07:42:44< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119451819
20160330 07:42:44-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 07:43:12< vultraz> without
20160330 07:43:14< vultraz> it shows with
20160330 07:43:15< ancestral> Okay, this makes sense
20160330 07:43:27< ancestral> Yeah, this is a problem
20160330 07:43:38< ancestral> vultraz: There is no Lato in your system
20160330 07:43:47< ancestral> And there is no font to load after Lato
20160330 07:44:29< vultraz> keep in mind I removed the line entirely
20160330 07:44:35< ancestral> Oh
20160330 07:44:40< ancestral> Hmm
20160330 07:44:54-!- Kwandulin [~Miranda@p200300760F191C4260ABBB35BAE38868.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160330 07:45:28< vultraz> doesn't work if I readd it though..
20160330 07:45:30< vultraz> oh 
20160330 07:45:31< vultraz> yeah
20160330 07:45:40< vultraz> ancestral: I think the stuff in [font] also has to be updated
20160330 07:45:43< vultraz> that's all gui1
20160330 07:45:53< vultraz> gui2 only need family_order
20160330 07:46:16< vultraz> needs
20160330 07:48:11< ancestral> Okay
20160330 07:48:12< ancestral> So
20160330 07:48:21< ancestral> It’s fine how it is
20160330 07:48:39< ancestral> (I just disabled Lato on my system, and things work as designed.)
20160330 07:50:56< vultraz> so it's good?
20160330 07:51:05< ancestral> Yes, the PR request is good
20160330 07:51:16< ancestral> Hey different question
20160330 07:52:00< ancestral> If I got the Steam trailer done, say tomorrow, would that put Wesnoth on Steam Greenlight almost immediately?
20160330 07:52:22< ancestral> Or are there other things that need to be done or need to wait?
20160330 07:56:52< vultraz> Depends
20160330 07:56:59< vultraz> If we need to deal with licensing now or later
20160330 07:57:28< vultraz> we can start, actually
20160330 07:58:08< vultraz> Plus, I'd like us to commission some splash art
20160330 07:58:52< vultraz> but we can certainly start quickly
20160330 08:02:14< ancestral> vultraz: When you say licensing, you do mean with regards to art and music, correct?
20160330 08:02:18< ancestral> *specifically
20160330 08:03:06< ancestral> There’s no need (at this time) to worry about licensing with code, yes?
20160330 08:06:42< irker535> wesnoth: Wedge009 wesnoth:master 808c3fb77919 / projectfiles/VC9/ (wesnoth.vcproj wesnothd.vcproj wesnothlib.vcproj): Updating load screen file locations (vcproj). https://github.com/wesnoth/wesnoth/commit/808c3fb77919c31bde57c81a11e8e157e86f04d4
20160330 08:14:47< vultraz> I don't think so
20160330 08:15:02< vultraz> But I'd still like to get the code copyrights assigned to the project
20160330 08:18:12< vultraz> ancestral: does this mean the trailer is near completion?
20160330 08:18:37< ancestral> It’s close. I actually have time now that everything is moved
20160330 08:18:45< ancestral> to my new house
20160330 08:28:38-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160330 08:34:59-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 08:35:41< zookeeper> < celticminstrel> Okay vultraz, so about C++11; I'll do nullptr and possibly range-for, and the #ifdef blocks; you'll do std::to_string; is there anything else we should do right away?
20160330 08:35:45< zookeeper> ^ so what's that about again?
20160330 08:42:35< Aginor> hey guys
20160330 08:43:22< Aginor> I'm not opposed to a move to c++11, but I want there to be a public post on the mailing list, stating which systems we would have to drop support for
20160330 08:43:27< Aginor> (if any)
20160330 08:43:48< zookeeper> very much so
20160330 08:44:08< Aginor> I just want there to be a proper formal announcement/discussion about it, to make sure we have considered the implications and potential risks/reprecussions of doing so
20160330 08:45:09< Aginor> doing it here in IRC is insufficient unless there is a meeting announced in advance, with a clear topic/agenda, at a time which is suitable to the timezones our active developers are from
20160330 08:45:43< Aginor> vultraz, celmin|sleep ^^^
20160330 08:45:55< vultraz> Well
20160330 08:45:57< Aginor> that's my opinion on the subject
20160330 08:46:03< vultraz> Then someone tell me what we're dropping
20160330 08:46:07< zookeeper> i have no idea about what sort of support issues that entails, but i also have no faith that those are getting any proper consideration instead of the codebase being treated as a personal playground.
20160330 08:47:08< Aginor> vultraz: OS X 10.6, VS9-2013, potentially debian oldstable, what else?
20160330 08:47:19< vultraz> I thought 2013 was good
20160330 08:47:25< Aginor> I don't know
20160330 08:47:30< Aginor> I'm not pushing for the change
20160330 08:47:47< Aginor> you tell me, make a list of affected versions, as that will be our new minimum dependencies
20160330 08:48:00< Aginor> it will vary across platforms
20160330 08:48:09< Aginor> will it affectour target platforms?
20160330 08:49:47< vultraz> as far as I remember from our discussions, there will be no issues
20160330 08:50:57< vultraz> vs 2013 support looks sufficient
20160330 08:51:06< vultraz> zookeeper is on vs 2013
20160330 08:51:27< vultraz> he can tell us if he can't compile something as we go on
20160330 08:51:39< vultraz> I can't answer about linux
20160330 08:51:42< vultraz> shadowm would know
20160330 08:51:48< zookeeper> <vultraz> he can tell us if he can't compile something as we go on
20160330 08:51:48< vultraz> and celmin|sleep would know about os x
20160330 08:52:02< zookeeper> so when i say that compiling fails, you're just gonna revert all your changes and do them differently?
20160330 08:52:02< vultraz> dropping 10.6 doesn't seem like a problem
20160330 08:52:04< zookeeper> is that a promise?
20160330 08:52:14< zookeeper> because if it's not, what you just said is completely meaningless
20160330 08:52:27< vultraz> of necessary, yes
20160330 08:52:43< vultraz> but I don't foresee us using features that you can't build
20160330 08:53:00< Aginor> vultraz: you are proposing a major technical change, which will cause lots of headaches if not managed properly
20160330 08:53:15< zookeeper> "if necessary", yeah, i bet that means that it won't ever be necessary because i can just change compilers or whatever.
20160330 08:53:50< Aginor> vultraz: I want you and celmin|sleep to do the homework before you do the major changes, so we can make informed decisions about what the impact is.
20160330 08:53:58< Aginor> it may be there is none, which is great
20160330 08:54:03< vultraz> You can update to vs 2015, yes, but you shouldn't have to
20160330 08:54:24< Aginor> but at this stage, I haven't seen sufficient evidence to be convinced of that
20160330 08:54:53< vultraz> Aginor: you said you were convinced last time we had this discussion :|
20160330 08:55:00< vultraz> (or maybe that was just about windows support..?)
20160330 08:55:29< Aginor> make a table of minimum dependencies before and after the switch, and which target platforms support the old vs new dependencies
20160330 08:55:50< Aginor> vultraz: that was about the two most recent versions of visual studio
20160330 08:56:19< Aginor> vultraz: your answer is only affirming my opinion that we need to do our due diligence beforehand
20160330 08:56:38< shadowm> vultraz: Stop trying to make me serve you answers on a silver plate. This is your job now, not mine, so you are the one who is supposed to do a (thorough) research.
20160330 08:56:58< vultraz> I do not run linux
20160330 08:57:09< shadowm> You have an Internet connection and know how to use Google.
20160330 08:57:14< vultraz> I'm looking to people to answer for the platforms they use
20160330 08:57:27< shadowm> I don't use every Linux distribution (big surprise).
20160330 08:57:30-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 08:57:31< travis-ci> wesnoth/wesnoth#9107 (ancestral-lato - 30fefe4 : Martin Proud): The build has errored.
20160330 08:57:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119456993
20160330 08:57:31-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 08:57:35< vultraz> You use debian
20160330 08:57:43< vultraz> This is specifically about debian oldstable
20160330 08:57:55< shadowm> Debian is not the only distribution in existence.
20160330 08:58:25< Aginor> vultraz: no, I mentioned debian oldstable before
20160330 08:58:36< Aginor> vultraz: it is not only about debian oldstable
20160330 08:58:56 * vultraz groans
20160330 08:58:58< vultraz> No
20160330 08:59:11< vultraz> I am asking, in this case, specifically whether debian oldstable will be dropped
20160330 08:59:16< vultraz> Not about other distros
20160330 08:59:21< vultraz> I'm asking about a *specific distro*
20160330 08:59:43< Aginor> vultraz: go use google, find out about c++11 support in different compiler versions
20160330 08:59:53< Aginor> vultraz: make a table of this on the wiki
20160330 08:59:58< shadowm> htt'l
20160330 09:00:05< shadowm> https://packages.debian.org/
20160330 09:00:32< Aginor> vultraz: then, use google, find the major linux distributions, find what verions of gcc they ship in CURRENTLY SUPPORTED versions
20160330 09:00:35< shadowm> There is a gcc package in every Debian version which depends on the latest well-supported gcc-X.Y for that distribution.
20160330 09:00:43< Aginor> vultraz: put that into a different table
20160330 09:00:55< shadowm> The Ubuntu counterpart of that database is http://packages.ubuntu.com/ .
20160330 09:01:25< shadowm> Very important since Ubuntu is like the beginner's first Debian distribution.
20160330 09:01:28< Aginor> vultraz: cross reference the two tables, to figure out which distributions have supported versions that ship with compatible gcc versions
20160330 09:01:32< shadowm> Debian-based distribution.
20160330 09:01:53< Aginor> repeat for os x, mingw, visual studio, clang, <random compiler/platform of choice>
20160330 09:02:44< Aginor> you may also need to repeat the exercise for c++-libraries
20160330 09:03:08< Aginor> post on the mailing list, with well constructed arguments before and against, with a recommendation
20160330 09:03:37< Aginor> vultraz: you may even wish to investigate the apache voting model for something like this
20160330 09:03:50< vultraz> The *what*??
20160330 09:04:02< Aginor> vultraz: the apache voting model
20160330 09:04:30< Aginor> vultraz: http://www.apache.org/foundation/voting.html
20160330 09:07:52< Aginor> vultraz: I'm not sprouting all of this to be difficult, but I am worried that we are introducing major changes that affect both the project and the users with a minimum of discussion. If you do all of them on a separate branch/fork and do a PR in the end, I would still be asking the same questions before giving it my thumbs up
20160330 09:09:11< Aginor> and no, I don't think IRC counts as an entirely appropriate venue for discussion for this because we don't have everyone affected here, meaning that they don't have a chance to put their opinion forward
20160330 09:21:54-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 09:21:55< travis-ci> wesnoth/wesnoth#9108 (master - 808c3fb : Wedge009): The build has errored.
20160330 09:21:55< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119464133
20160330 09:21:55-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 09:45:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 09:48:48 * zookeeper laments the ongoing lack of a simple IPF to invert alpha
20160330 09:49:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160330 09:51:22< zookeeper> (that is, you seem to have to use something like ~SWAP(alpha,alpha,alpha)~NEG()~SWAP(red,red,red,red) to achieve that)
20160330 09:51:44< zookeeper> (and that's assuming you don't care about the RGB values at all)
20160330 09:52:21< Aginor> hey zookeeper 
20160330 09:52:31< zookeeper> hey?
20160330 09:52:37< Aginor> we need to look at our alpha handling to make sure it's consistent
20160330 09:52:51< Aginor> keen? :D
20160330 09:52:54< zookeeper> what do you mean?
20160330 09:53:04< zookeeper> what sort of handling
20160330 09:53:21< Aginor> there's still compatability code around and colours that are defined with no alpha component
20160330 09:53:41< Aginor> it needs to be reviewed to make sure that it's all consistent with how SDL expects things
20160330 09:53:52< Aginor> and that surfaces are initialised nicely
20160330 09:54:48< zookeeper> well i don't really understand that stuff, so i doubt i can be of much help there
20160330 09:55:09< Aginor> I suspect some of it is simple refactoring
20160330 09:55:12< zookeeper> if none of it has implications WRT how things are actually getting rendered
20160330 09:55:31< Aginor> take the oodles of red() functions/macros and make sere that there is only one
20160330 09:55:43< Aginor> make sure that colour masking is done in the same way
20160330 09:55:45< Aginor> etc
20160330 09:56:02< Aginor> there's a bunch of duplication all over the place
20160330 09:56:45< zookeeper> i'm afraid my ventures to those parts of the code were mostly stabs in the dark and i don't really know anything about any of that :p
20160330 09:56:59< Aginor> zookeeper: that's how I started to :)
20160330 09:57:14< Aginor> now I know what I talk about on occasion
20160330 09:58:30< zookeeper> well, i can't really afford to take on something like low-level surface handling refactoring
20160330 09:59:38< Aginor> :D
20160330 09:59:50< Aginor> that's why I stay away from the WML stuff
20160330 10:00:05< zookeeper> i've been trying to get my mindset out of wesnoth-land for months now so i could focus on something else for a bit, and keep failing
20160330 10:00:57< Aginor> this is probably going to upset people - but I contribute on wesnoth as a hobby on the fun, I have a whole bunch of other things that eat my time too :)
20160330 10:01:24< zookeeper> lies!
20160330 10:01:57< Aginor> I try not to take it too seriously, although on occasion I fail and channel work-me
20160330 10:03:47< zookeeper> i have another project that really sort of requires my presence, and i find it awkward to try to seriously work on both simultaneously, so i've been trying to get at least all my terrain stuff out of the way first
20160330 10:04:00< Aginor> fair enough
20160330 10:35:50-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160330 10:52:33-!- NosajIRL [~nos@208.91.185.104] has quit [Ping timeout: 240 seconds]
20160330 11:01:21-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160330 11:06:56-!- irker535 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160330 11:07:13-!- NosajIRL [~nos@208.91.185.104] has joined #wesnoth-dev
20160330 11:19:12-!- Kwandulin [~Miranda@p200300760F191C4260ABBB35BAE38868.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160330 11:23:22< wedge009> zookeeper: Are you still having difficulty compiling? Compiling master is okay for me in VC14 today.
20160330 11:23:49< zookeeper> wedge009, nope, it's okay now.
20160330 11:24:22< wedge009> Cool.
20160330 11:35:09< zookeeper> had to hunt for it a long time though
20160330 11:42:39< wedge009> zookeeper: You needed to change something?
20160330 11:43:15< zookeeper> https://github.com/wesnoth/wesnoth/commit/41095c11e6a49745849ec6481a1b634547bc5949
20160330 11:43:36< zookeeper> i don't know if that commit actually caught everything that needed changing, i changed similar stuff in the other file too locally
20160330 12:09:42-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 244 seconds]
20160330 12:25:17-!- Kwandulin [~Miranda@2003:76:f19:1c42:a8fe:ce0a:d131:b90e] has joined #wesnoth-dev
20160330 12:28:06-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160330 12:36:28-!- Kwandulin [~Miranda@2003:76:f19:1c42:a8fe:ce0a:d131:b90e] has quit [Ping timeout: 250 seconds]
20160330 12:48:32< wedge009> Oh, I missed the lua_object update. That's probably what fixed it.
20160330 12:59:58-!- Kwandulin [~Miranda@p200300760F191CBAA8FECE0AD131B90E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160330 13:01:45-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160330 13:12:45-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160330 13:15:09-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 276 seconds]
20160330 13:31:24-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160330 13:48:42-!- irker509 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160330 13:48:42< irker509> wesnoth: gfgtdf wesnoth:master 60653e2632f1 / src/global.hpp: ignore c4477 msvc warning. https://github.com/wesnoth/wesnoth/commit/60653e2632f193d8f4b1f78b7610394faf90f936
20160330 13:48:42< irker509> wesnoth: gfgtdf wesnoth:master f9ee42c80d4a / src/gui/widgets/ (tree_view_node.cpp tree_view_node.hpp): fix linked groups in treeview nodes https://github.com/wesnoth/wesnoth/commit/f9ee42c80d4a754e5be70f54bfd9dd676032fe88
20160330 13:48:43< irker509> wesnoth: gfgtdf wesnoth:master 99bbaaeff4b5 / src/ (7 files in 2 dirs): make loadingscreen more responsive to user input. https://github.com/wesnoth/wesnoth/commit/99bbaaeff4b58d4e5ad75abd20614de918f8d98f
20160330 13:48:44< irker509> wesnoth: gfgtdf wesnoth:master 3df040502536 / src/gui/dialogs/ (loadscreen.cpp loadscreen.hpp): fix wait cursor on titlescren. https://github.com/wesnoth/wesnoth/commit/3df040502536606ae2ed76c6b2aa52474b81e138
20160330 13:48:45< irker509> wesnoth: gfgtdf wesnoth:master e6c58dcc1ac3 / src/display.cpp: fix segfault during loadingscreen. https://github.com/wesnoth/wesnoth/commit/e6c58dcc1ac3ea2e161b69dc2c7f1e46841e389c
20160330 13:48:46< irker509> wesnoth: gfgtdf wesnoth:master 53e527acc7fb / / (3 files in 2 dirs): show current stage in loadingscren. https://github.com/wesnoth/wesnoth/commit/53e527acc7fbd547a3d3b95e73922e4cd560db59
20160330 13:49:22-!- gfgtdf [~chatzilla@f054057118.adsl.alicedsl.de] has joined #wesnoth-dev
20160330 13:49:42< gfgtdf> celmin|sleep, vultraz: i pushed my tiltescren chages ^
20160330 13:54:15-!- ideuler [~textual@gwcesium.di.uminho.pt] has joined #wesnoth-dev
20160330 14:06:36-!- mjs-de [~mjs-de@x4db53e27.dyn.telefonica.de] has joined #wesnoth-dev
20160330 14:09:14< vultraz> gfgtdf: I'm a little confused about your change to show()
20160330 14:09:23< vultraz> you call tdialog::show() and then return?
20160330 14:10:34< gfgtdf> vultraz: y i basicalyl remove teh custom show
20160330 14:10:43< gfgtdf> vultraz: forgot to remove it complteley
20160330 14:10:50-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 14:10:51< travis-ci> wesnoth/wesnoth#9109 (master - 53e527a : gfgtdf): The build failed.
20160330 14:10:51< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119533497
20160330 14:10:51-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 14:10:57< gfgtdf> vultraz: the current version is more like a testign version
20160330 14:12:40-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 244 seconds]
20160330 14:16:54< vultraz> looks like I'll need to rebuild boost for c++11 
20160330 14:17:02< vultraz> s/for/with
20160330 14:17:25< vultraz> else spams my compiler output with warnings about auto_ptr being deprecated in boost >_>
20160330 14:18:24< gfgtdf> vultraz: hmm you coudl just add that warnign to the ignorelist.
20160330 14:21:02-!- prkc [~prkc@192.40.89.13] has quit [Ping timeout: 260 seconds]
20160330 14:29:06-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 14:30:05-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160330 14:33:40< irker509> wesnoth: mattsc wesnoth:master 91130a3df28f / data/ai/scenarios/scenario-formula.cfg: Fix error in Formula AI test scenario https://github.com/wesnoth/wesnoth/commit/91130a3df28f92146688498614855c8e1ec3823a
20160330 14:34:02< mattsc> celmin|sleep: ^ that fixes the error in the formula test scenario.
20160330 14:35:15< mattsc> The id was renamed from castle to human_castle (in Nov 2013, 1.11.8), so I could also have made that change, but I figured that checking whether this is castle terrain is better anyway.
20160330 14:35:34< mattsc> celmin|sleep: I also tested the Fast MAI and all seems to work.
20160330 14:36:40-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has joined #wesnoth-dev
20160330 14:36:43< mattsc> So I think all I have left to do is fix the bats in the Goto scenario, which I will be doing by making the id a required key for deleting and changing MAIS.
20160330 14:37:46< mattsc> celmin|sleep: the neares_loc() function does not appear to be documented on the wiki.
20160330 14:37:56< mattsc> *nearest_loc()
20160330 14:39:36-!- ideuler [~textual@gwcesium.di.uminho.pt] has quit [Ping timeout: 246 seconds]
20160330 14:40:28< irker509> wesnoth: gfgtdf wesnoth:master e1777a1f140d / / (3 files in 2 dirs): testing loadingscreen animation https://github.com/wesnoth/wesnoth/commit/e1777a1f140d427f15acca6f80c276d86dc31d18
20160330 14:40:30< irker509> wesnoth: gfgtdf wesnoth:master 0d190080ee18 / src/gui/dialogs/ (loadscreen.cpp loadscreen.hpp): remove tloadingscreen::show https://github.com/wesnoth/wesnoth/commit/0d190080ee1837bcc34582634b0dd2f7a3f52908
20160330 14:41:23< mattsc> Hmm, it is documented at FormulaAI, just not a WFL.  Maybe that’s intentional.
20160330 14:41:52< mattsc> sorry: FormulaAI_Functions
20160330 14:52:17-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has quit [Remote host closed the connection]
20160330 14:53:03-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160330 14:53:52-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has joined #wesnoth-dev
20160330 15:00:55-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 15:00:56< travis-ci> wesnoth/wesnoth#9110 (master - 91130a3 : mattsc): The build is still failing.
20160330 15:00:57< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119545890
20160330 15:00:57-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 15:05:49< irker509> wesnoth: gfgtdf wesnoth:master 036018494212 / src/play_controller.cpp: add comment https://github.com/wesnoth/wesnoth/commit/0360184942121e75460f1c309a2b758abdce284e
20160330 15:10:36-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 15:10:37< travis-ci> wesnoth/wesnoth#9111 (master - 0d19008 : gfgtdf): The build is still failing.
20160330 15:10:37< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119547408
20160330 15:10:37-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 15:15:24-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 276 seconds]
20160330 15:17:13-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160330 15:27:22-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160330 15:28:49-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 15:28:50< travis-ci> wesnoth/wesnoth#9112 (master - 0360184 : gfgtdf): The build is still failing.
20160330 15:28:50< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119554745
20160330 15:28:50-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 15:38:46-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160330 15:38:56-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has quit [Ping timeout: 244 seconds]
20160330 15:40:21< vultraz> ..ughh
20160330 15:40:35< vultraz> trying to build with c++11 and what is this :| log_windows.cpp|345|error: '_wrename' was not declared in this scope|
20160330 15:44:19-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160330 15:46:57< vultraz> and _wfreopen
20160330 15:48:37< vultraz> hm. including <stdio.h> seems to fix that
20160330 15:49:31< vultraz> zookeeper: when building with c++11, you're gonna want to enable  -Wno-deprecated-declarations 
20160330 15:51:27< vultraz> celmin|sleep: additional entry to c++11 todo list: expand OVERRIDE and AUTO macros.
20160330 15:52:58-!- Kwandulin [~Miranda@p200300760F191CBAA8FECE0AD131B90E.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160330 15:53:25< irker509> wesnoth: ln-zookeeper wesnoth:master 085afa0e4a23 / src/terrain/ (builder.cpp builder.hpp): Added optional [tile] no_draw=<bool> to exclude images from a hex https://github.com/wesnoth/wesnoth/commit/085afa0e4a23092ab65653ce481b267243f457a3
20160330 15:55:24-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 16:00:35-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160330 16:10:45< celmin|sleep> Aginor, zookeeper, etc: I think new minimums would be OSX 10.7 (dropping 10.6) and MSVC 2013; it's not even necessary to drop XP support, though it may be easier to do so. And I'm not sure on Linux, so that needs investigation.
20160330 16:10:47< celmin|sleep> mattsc: About nearest_loc, yeah, that's intentional since it's only available in FormulaAI (though I may change that; some of the FAI functions aren't really AI-specific).
20160330 16:10:48< celmin|sleep> vultraz: Based on the discussions between you, Aginor, and zookeeper... what do you think about doing the C++11 changes on a public branch? (ie a branch in the main repo) Also, have you done that research yet? Are you working on composing a mailing-list post?
20160330 16:12:23< vultraz> I don't think it's worth doing it in a private branch, as long as we can confirm we first can build with -std=c++11
20160330 16:12:30< vultraz> and no I haven't started the research yet
20160330 16:14:27< vultraz> public branch, that is
20160330 16:14:41< gfgtdf> celmin|sleep: which c++ changes do you mean ?
20160330 16:15:19< vultraz> gfgtdf: stuff like expanding the OVERRIDE and AUTO macros, lexical_cast<std::string> -> std::to_string, using nullptr, etc.
20160330 16:15:38-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 16:15:39< travis-ci> wesnoth/wesnoth#9113 (master - 085afa0 : ln-zookeeper): The build is still failing.
20160330 16:15:39< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119568138
20160330 16:15:39-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 16:17:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 16:17:25< irker509> wesnoth: ln-zookeeper wesnoth:master c3bf0ee81619 / data/core/terrain-graphics/new-macros.cfg: Improved on some glitchy 3-way corners involving beach waves https://github.com/wesnoth/wesnoth/commit/c3bf0ee816193da97b58abfd3a477b722be404e2
20160330 16:17:30< zookeeper> phewwww...
20160330 16:17:33< zookeeper> that took a long time
20160330 16:19:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 16:19:26-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 16:20:50-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160330 16:24:09< celmin|sleep> vultraz: I said public branch - like ancestral is doing with Lato.
20160330 16:24:28< celmin|sleep> gfgtdf: Like NULL->nullptr for example.
20160330 16:25:37< celmin|sleep> vultraz: Oh, I guess you just misspoke. So you don't think that's worth it. Alright, whatever.
20160330 16:25:56< celmin|sleep> Admittedly, such a branch would almost certainly cause conflicts on merge, but I don't think that's a problem.
20160330 16:27:01< celmin|sleep> Do we have to investigate every Linux distro that has a package for Wesnoth, or only major Linux distros?
20160330 16:27:29< celmin|sleep> eg Debian, Ubuntu, Mint
20160330 16:27:35-!- celmin|sleep is now known as celticminstrel
20160330 16:28:59< gfgtdf> any opinions on the current loadinscreen ?
20160330 16:29:12< celticminstrel> Haven't looked yet. Let me eat something first.
20160330 16:29:42< celticminstrel> It looks like Debian stable has GCC 4.9.
20160330 16:30:11< celticminstrel> Oldstable has 4.7.
20160330 16:30:16< celticminstrel> I think.
20160330 16:30:30< celticminstrel> Not entirely sure how to parse these version numbers; it may be as old as 4.4.
20160330 16:31:01< celticminstrel> However, there are specific packages on oldstable for 4.7.
20160330 16:34:41< vultraz> gfgtdf: I'll look at it soon
20160330 16:34:48< vultraz> trying to build with boost 1.60
20160330 16:34:51< celticminstrel> I can't figure out Mint.
20160330 16:35:31< gfgtdf> vultraz: you are currently building boost 1.60 ?
20160330 16:36:41< gfgtdf> hmm for some reason there is no loading screen anymore after clicking multiplayer
20160330 16:36:54< celticminstrel> Ubuntu 12 appears to only have up to GCC 4.6.
20160330 16:37:52< vultraz> Aren't we up to ubutu 15.10
20160330 16:37:56< celticminstrel> The latest is Ubuntu 15, yeah.
20160330 16:38:10< celticminstrel> I don't know how far back we need to consider, so I just took the oldest I could find info on.
20160330 16:38:39< vultraz> Latest LTS would be optimal
20160330 16:38:41< celticminstrel> Just for the record, Ubuntu 14 has GCC 4.8.
20160330 16:38:51< celticminstrel> No, we need to consider more than just the latest.
20160330 16:39:06< vultraz> I meant latest long term support
20160330 16:39:17< celticminstrel> Oh, right.
20160330 16:39:21< celticminstrel> That's what LTS means.
20160330 16:39:29< celticminstrel> Yeah, that seems reasonable to me.
20160330 16:39:58< vultraz> gfgtdf: I built boost 1.60 but when I try to build I get errors saying .objs-release\src\addon\client.o:client.cpp|| undefined reference to `boost::system::system_category()'|
20160330 16:40:05< vultraz> I got this before, couldn't fix it :|
20160330 16:40:19-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 16:40:20< travis-ci> wesnoth/wesnoth#9114 (master - c3bf0ee : ln-zookeeper): The build is still failing.
20160330 16:40:20< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119574918
20160330 16:40:20-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 16:40:38< gfgtdf> vultraz: hmm says nothing to me, did you look in the internnet for it ?
20160330 16:40:56< vultraz> I've looked
20160330 16:41:00< vultraz> couldn't find anything that worked
20160330 16:43:13-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has joined #wesnoth-dev
20160330 16:43:20< vultraz> guess I have to go back to 1.58 again :|
20160330 16:43:26< gfgtdf> vultraz: is that a linker or cimpiler error ?
20160330 16:43:31< vultraz> linker
20160330 16:44:15< gfgtdf> vultraz: maybe some library is notincluded in linking
20160330 16:44:38< gfgtdf> vultraz: you coudl try the " -lsomelib.lib" flag
20160330 16:44:52< gfgtdf> vultraz: not sure how to do it on non-msvc
20160330 16:49:41< celticminstrel> -lboost_filesystem seems likely in this case.
20160330 16:49:52< celticminstrel> But it's possible this link error means the function was removed.
20160330 16:50:14< celticminstrel> If you were still using older headers, that might not be detected at compile time.
20160330 16:50:51< celticminstrel> So besides Ubuntu and Debian, what other distros should we be investigating? Every distro that ships Wesnoth?
20160330 16:51:18< celticminstrel> vultraz: I think Ubuntu 12 may still be on long term support.
20160330 16:51:29< vultraz> Probably, yes
20160330 16:51:45< celticminstrel> Since it's listed as "12.04LTS".
20160330 16:51:46< vultraz> and I'm not using old headers
20160330 16:51:54< celticminstrel> But there's also "14.04LTS".
20160330 16:52:17< vultraz> then we want to try to target that as minimum 
20160330 16:53:49< celticminstrel> vultraz: So about which distros to check - should we just pick several big ones (eg Ubuntu, Debian), or try to find every distro that ships a wesnoth package, or what?
20160330 16:53:49-!- NosajIRL [~nos@208.91.185.104] has quit [Ping timeout: 248 seconds]
20160330 16:54:09< vultraz> I'd say Ubuntu, Debian, and Mint
20160330 16:54:40< celticminstrel> I'd say Fedora too, but I'm guessing that one won't be a problem. Are there really only three main ones though? I feel like there should be a few more.
20160330 16:54:51< vultraz> freebsd? 
20160330 16:54:55< vultraz> do we have a package there?
20160330 16:55:01< celticminstrel> I dunno.
20160330 16:55:34< celticminstrel> Heh, just found it on the Fedora wiki.
20160330 16:58:49-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160330 16:58:49-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160330 17:00:29< vultraz> gaaahhh
20160330 17:00:32< vultraz> these
20160330 17:00:33< vultraz> ERRORS
20160330 17:04:46< vultraz> and why are they in addon/client.cpp :|
20160330 17:05:16< vultraz> there's nothing in this file that has to do with system
20160330 17:06:40< vultraz> only thing I can think of is that it includes addons/manager which includes filesystem.hpp
20160330 17:10:22-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 17:11:33-!- Kwandulin [~Miranda@p200300760F191CBACCA43FF26338FB84.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160330 17:16:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 17:18:22< celticminstrel> FreeBSD stable seems to have GCC 4.8. I'm not sure I can find info on FreeBSD 9.
20160330 17:19:21< gfgtdf> vultraz: hmm addon client seems to be the only cases that useds boost asio to maybe its related to boost asio
20160330 17:19:50< gfgtdf> vultraz: does it wor when you add #include <boost/thread.hpp> there ?
20160330 17:20:04< gfgtdf> work*
20160330 17:20:55< celticminstrel> Any other distros I should check?
20160330 17:22:23< celticminstrel> Fedora 21 has GCC 4.9, older information doesn't seem to be available. (Latest is Fedora 24.)
20160330 17:23:40 * celticminstrel finds something called "Mandriva" at the same place as Fedora, but since its latest Wesnoth is 1.10.4, I don't think we need to worry about it.
20160330 17:24:48< celticminstrel> Maybe I should check SUSE something.
20160330 17:25:20-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has quit [Ping timeout: 244 seconds]
20160330 17:26:22< celticminstrel> Or Gentoo.
20160330 17:26:31< Aginor> celticminstrel: I think it'd be good to record this in the wiki as well so that we can reference it from the mailing list
20160330 17:26:44< celticminstrel> Aginor: Record what exactly?
20160330 17:27:05< Aginor> celticminstrel: youd findings about gcc versions in different distros and their c++11 support
20160330 17:27:20< Aginor> at least that's what I'm assuming you're investigating :)
20160330 17:27:30< celticminstrel> So, should I put it on some existing page, add a new main namespace page, or make a page in my userspace?
20160330 17:27:48< Aginor> whatever you think is appropriate :)
20160330 17:28:01< celticminstrel> Maybe I should check Slackware as well.
20160330 17:28:41< celticminstrel> I wonder if Arch Linux is sufficiently major; it's significant enough that I've heard of it before.
20160330 17:29:09< Aginor> arch linux is more mainstream than gentoo nowadays I think
20160330 17:29:10-!- SigurdFD [~SigurdFD@dynamic-acs-72-23-176-151.zoominternet.net] has joined #wesnoth-dev
20160330 17:29:35< celticminstrel> Should I check SteamOS or assume that it's roughly in line with Debian?
20160330 17:29:35< Aginor> http://distrowatch.com/dwres.php?resource=major
20160330 17:30:06< Aginor> http://distrowatch.com/dwres.php?resource=popularity
20160330 17:30:25< celticminstrel> I was looking at Wikipedia's list just now.
20160330 17:30:55< Aginor> fair enough
20160330 17:31:06< celticminstrel> I'm ignoring CentOS.
20160330 17:31:08-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 17:31:57< Aginor> why?
20160330 17:32:27< Aginor> that one is used a lot across universities
20160330 17:32:43< celticminstrel> But it's far behind in packages, by design.
20160330 17:33:04-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has joined #wesnoth-dev
20160330 17:33:18< SigurdFD> Was any c++11 rolled out already? (other than travis) My win compile broke.
20160330 17:33:30< celticminstrel> Not yet, not - just Travis so far.
20160330 17:33:34< celticminstrel> So OpenSUSE, Gentoo, Slackware, Arch Linux, and Mint still need to be checked, at least.
20160330 17:33:47< celticminstrel> SigurdFD: What's the error message?
20160330 17:33:53< celticminstrel> ^no not not
20160330 17:34:39< SigurdFD> it looks like there's 11 stuff in it. http://pastebin.com/VdgUastb
20160330 17:34:54< celticminstrel> Even though I said I'm ignoring CentOS, it looks like it actually has GCC 4.8 in the latest release. (I think that's considered an unstable release, but still.)
20160330 17:35:20< celticminstrel> Oh, right, I forgot gfgtdf used some lambdas.
20160330 17:35:32< celticminstrel> That probably shouldn't've been merged immediately.
20160330 17:35:46< celticminstrel> Oh well...
20160330 17:36:53< celticminstrel> SigurdFD: is C++11 a problem for you, or is it only a matter of enabling flags?
20160330 17:37:24-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160330 17:38:25< SigurdFD> I'm not sure.... I'm hoping recompling boost is all I'd have to do. If it's flags, I don't know where to look.
20160330 17:38:26< celticminstrel> BTW Aginor, thanks for that link.
20160330 17:38:49< celticminstrel> SigurdFD: You're using MinGW and scons, I'm guessing?
20160330 17:39:39< SigurdFD> yes, as listed here: https://forums.wesnoth.org/viewtopic.php?f=5&t=40694
20160330 17:39:51< celticminstrel> The SConstruct has not yet been updated to make C++11 the default, so you'll need to pass cxx0x=true to scons until we get to that.
20160330 17:40:03< celticminstrel> Which should hopefully be soon.
20160330 17:40:05< SigurdFD> I'm looking to switch to pr616 if/when it's accepted
20160330 17:40:24< celticminstrel> I want to get the announcement done before actually doing any further C++11 update things.
20160330 17:40:27< SigurdFD> but that still uses mingw/scons
20160330 17:40:35< celticminstrel> What's PR616?
20160330 17:40:51< celticminstrel> Oh, right, the bootstrap.py?
20160330 17:41:22< celticminstrel> OpenSUSE has GCC 4.7 from version 12.2.
20160330 17:41:38< SigurdFD> yes
20160330 17:41:48< celticminstrel> I think 12.2 is quite old though.
20160330 17:42:30-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 17:42:54< celticminstrel> Arch Linux seems to be rather behind; looks like GCC 4.5 unless you're on the current release, though there's one release in between with no info.
20160330 17:43:24< celticminstrel> Mint 14 has GCC 4.7. The latest Mint is 17.3.
20160330 17:44:41< celticminstrel> Slackware 14.0 has GCC 4.7. Latest is 12.2, so that's pushing it a little. Slackware 13 has GCC 4.5.
20160330 17:45:22< celticminstrel> I know I mentioned FreeBSD already, but 9.3 has GCC 4.7, so I think there's nothing to worry about there.
20160330 17:45:42< celticminstrel> SteamOS has GCC 4.7. There's nothing older.
20160330 17:46:23< celticminstrel> Gentoo from 2014 has GCC 4.8; the next oldest from 2012 has GCC 4.6.
20160330 17:46:44< loonycyborg> what gcc does debian jessie have?
20160330 17:47:32< celticminstrel> RHEL 7.2 has GCC 4.8, and 6.7 has GCC 4.4. Is that a problem? I suspect not (RHEL isn't that popular, right?), but not 100% sure.
20160330 17:48:19< celticminstrel> Ubuntu seems to have 4.7 as far back as version 13. We clearly don't need to worry about Ubuntu at all.
20160330 17:48:58< celticminstrel> OpenBSD has GCC 4.9 for the two latest versions, but before that it's GCC 4.2.
20160330 17:50:01< celticminstrel> Debian has 4.7 as far back as version 12.10.
20160330 17:50:18< celticminstrel> Wait, that was Ubuntu.
20160330 17:50:50< celticminstrel> Debian 7.0 has FCC 4.7. Debian 6.0 however has GCC 4.4.
20160330 17:50:55< celticminstrel> ^GCC
20160330 17:51:33< celticminstrel> I think Debian 6 isn't important, though. Debian "oldstable" was GCC 4.7, so that's probably Debian 7.
20160330 17:54:47< celticminstrel> I think targeting GCC 4.7 and MSVC 2013 would be acceptable, but now I'm looking at the compiler support table to make sure.
20160330 17:56:29< celticminstrel> MSVC 2013 is MSVC 12, right?
20160330 18:02:51< celticminstrel> So, with GCC4.7/MSVC12, we miss the following C++11 features: alignas/alignof (who cares!), C99 preprocessor (eg variadic macros), constexpr, inheriting constructors, inline namespaces (whatever that is), Unicode character/string types (not really important), user-defined literals (not really important), unrestricted unions ( :( ), attributes, ref-qualifiers, "magic statics", noexcept (but there's already throw() if we really needed
20160330 18:02:52< celticminstrel> that); and decltype is not fully standards-conforming pre-GCC-4.8, while r-value references are not fully standard-conforming in MSVC 2013.
20160330 18:03:13< celticminstrel> The only one of those that I really care about is unrestricted unions.
20160330 18:03:29< celticminstrel> Also, that only covers language support, not library support.
20160330 18:04:30< celticminstrel> loonycyborg: Debian 8 (jessie) has GCC 4.9.
20160330 18:05:18< celticminstrel> Aginor: So about putting this on the wiki, what exactly are you suggesting I do?
20160330 18:05:46< celticminstrel> Just make a new page listing (or tabling?) my findings?
20160330 18:08:16-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 18:14:07< zookeeper> ah, lucky day... terrain builder picks a 4-hex desert mountain tile for the 4-hex pinnacle rock.
20160330 18:15:36< Aginor> celticminstrel: yes
20160330 18:15:57< Aginor> celticminstrel: I outlined my suggestion some 9 hours ago
20160330 18:16:01< celticminstrel> Aginor: So a userspace page would be fine?
20160330 18:16:07< Aginor> yes
20160330 18:16:11< celticminstrel> 'kay
20160330 18:16:22< Aginor> I'm going to disappear now
20160330 18:17:22< gfgtdf> celticminstrel: hmm i changes resilution to the minimum solution and wesnoth won't start anymore
20160330 18:17:36< celticminstrel> gfgtdf: 800x480?
20160330 18:17:49< gfgtdf> celticminstrel: hmm not sure
20160330 18:17:53< celticminstrel> vultraz wants to drop that one.
20160330 18:17:58< celticminstrel> I've been using 800x600.
20160330 18:17:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 18:18:07< gfgtdf> celticminstrel: the minimum resolution.
20160330 18:18:07< SigurdFD> zookeeper, vultraz: is one of you likely to be reviewing any pr's I'd make for HttT?
20160330 18:18:12< celticminstrel> If that breaks, I'll be annoyed. :P
20160330 18:18:32< zookeeper> SigurdFD, well, depends on what they're about
20160330 18:19:51< SigurdFD> some would be simple, like clarifying objectives and stuff for S10 Gryphon mountain
20160330 18:20:19< SigurdFD> others, more involved, like fixing 19cCoT & 20bUC
20160330 18:21:12< zookeeper> well, sure, although i'd suggest some discussion about the latter kind beforehand
20160330 18:21:17-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 18:21:22< SigurdFD> though my overall approach is going to be somewhat minimalist; most of what I've read about proposed fixes seems unnecsarrly ambitious
20160330 18:22:05< gfgtdf> celticminstrel: hmm it semes liek something goes wrong: whn i try with 800x480 it says faile: wanted size if 610,550. If i trs with 800x600 size it says: failed wanted size it 610,607
20160330 18:22:06-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 18:22:11< SigurdFD> yes, something like 19c& 20b, I'll start with running a propsed outline past you.
20160330 18:22:35< celticminstrel> gfgtdf: Can you determine which dialog is failing?
20160330 18:22:44< celticminstrel> Is it the loadscreen? Titlescreen? Something else?
20160330 18:22:57< gfgtdf> celticminstrel: loaginsscreen
20160330 18:23:00< zookeeper> SigurdFD, all good as far as i'm concerned then
20160330 18:23:11< SigurdFD> with what I have in mind for 10_GM, I'm just gonna submit a pr first.
20160330 18:23:55< SigurdFD> unless it ends up being more complex than what I have in mind
20160330 18:24:07< zookeeper> yeah, sure
20160330 18:24:17< SigurdFD> ok\
20160330 18:24:18< celticminstrel> gfgtdf: You changed the loadscreen WML?
20160330 18:24:26< gfgtdf> celticminstrel: hmm i think this is relatd to this 'padding' row whose size if defeined as 'screen_size/4'
20160330 18:24:39< celticminstrel> gfgtdf: That does seem like a bad idea.
20160330 18:25:24< gfgtdf> celticminstrel: i added one label but i'm quite sure that it'd also fail befor on 800x480 resolution
20160330 18:25:54< celticminstrel> gfgtdf: It was working on 800x600 before, though.
20160330 18:29:30< irker509> wesnoth: gfgtdf wesnoth:master 6910083e8633 / src/ (game_config_manager.cpp game_initialization/multiplayer_ui.cpp): fix loading screen when loading mp config. https://github.com/wesnoth/wesnoth/commit/6910083e86335c78412a88e2f26e49cc20ae6adc
20160330 18:29:33< irker509> wesnoth: gfgtdf wesnoth:master 2b565b9abe0c / data/gui/window/loadscreen.cfg: fix loadingscreen for small resolutions. https://github.com/wesnoth/wesnoth/commit/2b565b9abe0c75cfeaf42846ef8b4aaf72f72f2d
20160330 18:31:49-!- NosajIRL [~nos@208.91.185.104] has joined #wesnoth-dev
20160330 18:32:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 18:34:37-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Ping timeout: 252 seconds]
20160330 18:36:47-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 18:37:52-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 18:43:54-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160330 18:44:00-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160330 18:44:03< celticminstrel> vultraz, Aginor: https://wiki.wesnoth.org/User:Celtic_Minstrel/WesnothCxx11Support
20160330 18:44:09< celticminstrel> The results of my investigation.
20160330 18:44:21< celticminstrel> Next: Try gfgtdf's loading screen and update the XCode project.
20160330 18:44:36< gfgtdf> hmm for some reason i cannot play campaigsn anymore
20160330 18:44:41< celticminstrel> (Probably in reverse order, as the former may depend on the latter.)
20160330 18:44:48< celticminstrel> gfgtdf: This is very bad. Please fix. :P
20160330 18:44:49< gfgtdf> last time i tested the new loadingscreen it did work
20160330 18:49:23-!- NosajIRL [~nos@208.91.185.104] has quit [Quit: Leaving]
20160330 18:50:18-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has joined #wesnoth-dev
20160330 18:51:22< zookeeper> there's something terribly wrong with the map editor and starting location placement.
20160330 18:51:59-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 18:52:00< travis-ci> wesnoth/wesnoth#9115 (master - 2b565b9 : gfgtdf): The build is still failing.
20160330 18:52:00< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119609574
20160330 18:52:00-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 18:52:40< zookeeper> namely, it screws up starting positions on save... but only in the saved file; the screwup doesn't show up in the editor until you reload the map.
20160330 18:53:31< zookeeper> to reproduce: open a map, make any single-hex change in it, save. check the map diff.
20160330 18:55:34< zookeeper> i presume someone has made a massive logic error somewhere, because it puts side 1 starting position to 1,1, side 2 to 2,2, side 3 to 3,3...
20160330 18:56:50-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 18:58:26< zookeeper> celticminstrel, vultraz, gfgtdf, ^
20160330 18:58:52< gfgtdf> zookeeper: hmm im busy wit the loadingscreen oissue currently
20160330 18:59:32< zookeeper> well, i included you just because you had that one commit that did something relating to starting positions.
20160330 18:59:58< zookeeper> looked harmless to me, but didn't want to make assumptions :p
20160330 19:00:51-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 19:08:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 19:09:37< irker509> wesnoth: gfgtdf wesnoth:master 249792e08d47 / src/ (game_display.cpp play_controller.cpp): fix segfault in loadingscreen when staring campaigns, https://github.com/wesnoth/wesnoth/commit/249792e08d476c51452639edb93171b0f9aa944e
20160330 19:09:56< gfgtdf> Aginor: i don'T really know what video2::draw_layering does, could you please check this commit ^ whether you see any issues in it?
20160330 19:10:08< celticminstrel> Wow, a segfault when staring at campaigns? ;)
20160330 19:10:25< gfgtdf> celticminstrel: ?
20160330 19:10:36< gfgtdf> celticminstrel: ah right
20160330 19:10:36< zookeeper> they're shy
20160330 19:10:46< celticminstrel> XD
20160330 19:11:04-!- ziro_ [026855cc@gateway/web/freenode/ip.2.104.85.204] has joined #wesnoth-dev
20160330 19:12:37-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has quit [Ping timeout: 268 seconds]
20160330 19:15:46< celticminstrel> gfgtdf: So, have you tested loadscreen in all the following situations? Map editor; multiplayer; campaigns; pressing F5 at titlescreen; tutorial; tests launched from command-line.
20160330 19:16:54< celticminstrel> Well, it looks like my C++11 build works.
20160330 19:17:56-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160330 19:17:56-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160330 19:24:35-!- prkc [~prkc@46.166.138.167] has joined #wesnoth-dev
20160330 19:32:21< celticminstrel> Do we currently support Windows XP, by the way?
20160330 19:33:12< gfgtdf> celticminstrel: i'd say yes
20160330 19:33:35< gfgtdf> celticminstrel: afaik msvc14 also allows creating xp compatible executables
20160330 19:34:06< gfgtdf> celticminstrel: mingw most likeley too
20160330 19:34:40< gfgtdf> celticminstrel: i don't think we need to support building on xp though if this is a problem.
20160330 19:35:07< celticminstrel> I don't think there's any issue with continuing to support it, but I could be wrong.
20160330 19:37:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 19:38:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160330 19:41:03< celticminstrel> If possible, we should set up Travis to compile on GCC 4.7.
20160330 19:41:58< gfgtdf> celticminstrel: what does it currently use ?
20160330 19:42:06< celticminstrel> I don't know.
20160330 19:42:23 * celticminstrel checks the yml to see if it gives any clues.
20160330 19:42:43< celticminstrel> ...or I would, if TextWrangler was responsive...
20160330 19:43:08< celticminstrel> Oh wait, it's responsive, just not coming in front like it should.
20160330 19:43:24< celticminstrel> But becomes unresponsive as soon as I say that... :|
20160330 19:43:32< gfgtdf> celticminstrel: 4.8.4 it seems
20160330 19:43:46< celticminstrel> Is that specified in the yml, or...?
20160330 19:44:18< gfgtdf> celticminstrel: no ikooked at the travis output
20160330 19:44:39< gfgtdf> celticminstrel: seems leik travis gets spammed by 'auto_ptr wanrings'
20160330 19:44:53< gfgtdf> celticminstrel: well spammed it maybe too much
20160330 19:44:55-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 19:44:56< travis-ci> wesnoth/wesnoth#9116 (master - 249792e : gfgtdf): The build is still failing.
20160330 19:44:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119620137
20160330 19:44:56-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 19:45:05< gfgtdf> celticminstrel: its just that part i was looking at had a lot of tem
20160330 19:45:36< SigurdFD> celticmistrel: added cxx0x=true in the scons call, still errors, got http://pastebin.com/bVW2ryMt . Any suggestions? (I got those auto_ptr warnings too)
20160330 19:45:39< celticminstrel> Oh, it's failing now, that's not good.
20160330 19:47:02< celticminstrel> The auto_ptr warnings are just warnings.
20160330 19:47:11< celticminstrel> They should be fixed, but are not high priority.
20160330 19:47:31< gfgtdf> SigurdFD: it seems liek travis is getting the same error
20160330 19:47:44< gfgtdf> the undefined reference to `boost::detail::thread_data_base i mean
20160330 19:48:00< gfgtdf> SigurdFD: which boost version do you use ?
20160330 19:48:17< celticminstrel> Do we need to change line 54 of .travis.yml?
20160330 19:48:18< SigurdFD> this compile used 1.59
20160330 19:48:27< celticminstrel> (The line that installs Boost.)
20160330 19:48:37< SigurdFD> this/my
20160330 19:48:44< gfgtdf> celticminstrel: hmm no i think think so, version 1.59 seems to fail too so its mostlikeley something different
20160330 19:48:46< celticminstrel> (And SDL2 and other stuff.)
20160330 19:49:14< celticminstrel> Oh, wait.
20160330 19:49:16< gfgtdf> celticminstrel: i had no problemhere, but im on windows.
20160330 19:49:31< celticminstrel> The problem is that Boost.Thread wasn't yet in the dependencies.
20160330 19:49:54< gfgtdf> celticminstrel: hmm but wouldnt it then get an erro cannof find include boost/thread.hpp ?
20160330 19:50:20< gfgtdf> celticminstrel: also afaik boost asio and boost locale als use boost thread internally.
20160330 19:50:20< SigurdFD> I think that's the error I got at the bottom of my latest build attempt?
20160330 19:50:41< celticminstrel> Really? Asio makes sense, but locale?
20160330 19:50:59< celticminstrel> If they do, though, it would be installed by the dependency analysis...
20160330 19:52:38< gfgtdf> celticminstrel: well i remember that i once got a linker error related to boost thread in boost locale
20160330 19:53:17< celticminstrel> Well my C++11 build worked, but with linker warnings.
20160330 19:53:29< celticminstrel> I've gotten these before, but forget how to fix them.
20160330 19:53:58< gfgtdf> celticminstrel: warnings or errors ?
20160330 19:54:13< celticminstrel> Boost.Thread is listed in the XCode project, so you're probably right.
20160330 19:54:17< celticminstrel> Warnings. Not errors.
20160330 19:55:21< celticminstrel> eg "direct access in ___cxx_global_var_init46 to global weak symbol std::__1::set<compicated_stuff>::~set() means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings"
20160330 19:58:07< celticminstrel> Ahhh, I see, GUI2 is using auto_ptr instead of shared_ptr in some places.
20160330 20:00:47< gfgtdf> celticminstrel: the usualy relacement for auto_ptr is unique_ptr
20160330 20:00:50< gfgtdf> not hsared_ptr
20160330 20:01:08< celticminstrel> Fair enough.
20160330 20:06:05< loonycyborg> celticminstrel: gfgtdf: pretty sure boost.thread wasn't needed
20160330 20:06:32< gfgtdf> loonycyborg: for boost asio ?
20160330 20:06:39< loonycyborg> yup
20160330 20:07:13< loonycyborg> it has some direct calls to threading apis, without using boost.thread
20160330 20:12:01< gfgtdf> loonycyborg: i didnt know this
20160330 20:12:50< gfgtdf> loonycyborg: do linux builds need to explicitly give the boost libraries with -l parameter or are they known automatically ?
20160330 20:13:45< loonycyborg> all libs needed are added with -l flags
20160330 20:14:17< irker509> wesnoth: Celtic Minstrel wesnoth:master 94d3d5aec66d / run_wml_tests: Don't attempt every WML test if binary missing https://github.com/wesnoth/wesnoth/commit/94d3d5aec66d79b4739eb5c3a6c53989e39e90d8
20160330 20:14:17< celticminstrel> gfgtdf: Are you planning to update SConstruct?
20160330 20:14:19< irker509> wesnoth: Celtic Minstrel wesnoth:master acc752aa9a35 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: XCode: Build with C++11 and libc++ https://github.com/wesnoth/wesnoth/commit/acc752aa9a3515ba53c79aca3e0c7d3e19d3f51d
20160330 20:16:11< loonycyborg> celticminstrel: I can update sconstruct for switch to c++0x by default, but I thought there will be ml post about c++0x first
20160330 20:16:40< celticminstrel> I have a ML post drafted.
20160330 20:17:03< celticminstrel> Should I run it by a few people first? I feel like that would be a good idea.
20160330 20:17:28< gfgtdf> celticminstrel: no i dont really now how those work
20160330 20:17:45< celticminstrel> gfgtdf: Then I'll try adding the thread dependency.
20160330 20:18:29< gfgtdf> loonycyborg: on windows the libraries are included by the boost headers via #pramga lib .. is there an equivelent onlinux (even if it not used by boost)?
20160330 20:19:09< celticminstrel> gfgtdf: Should we require Boost.Thread for wesnothd or only for the client?
20160330 20:19:10< loonycyborg> none I know of
20160330 20:19:27< loonycyborg> we shouldn't require boost.thread at all I think
20160330 20:19:33< gfgtdf> celticminstrel: i think its currently onyl used by the client.
20160330 20:19:39< celticminstrel> loonycyborg: Why not?
20160330 20:19:59< loonycyborg> I don't know a particular need for it
20160330 20:20:07< loonycyborg> at least networking code shouldn't need it
20160330 20:20:16< gfgtdf> loonycyborg: latest master does use boost::thread
20160330 20:20:23< loonycyborg> what for?
20160330 20:20:32< celticminstrel> Loading screen.
20160330 20:20:55< celticminstrel> I'm pretty sure networking code is one place where you really want threads. Admittedly that doesn't necessarily imply Boost.Thread specifically.
20160330 20:21:12< loonycyborg> no, boost asio has different approach
20160330 20:21:26< loonycyborg> it can use threads but avoiding them is simpler
20160330 20:21:36< loonycyborg> to avoid the need for synchronization
20160330 20:22:09< loonycyborg> Threads should NOT be used unless you absolutely sure you need them
20160330 20:22:36< loonycyborg> because thread synchronization is very hard to understand and debug
20160330 20:23:10< celticminstrel> The only reason I've recommended using boost::thread instead of std::thread (for places that use threads) is because I recall MinGW was missing the <thread> header at some point.
20160330 20:23:29< loonycyborg> I've already switched to mingw64
20160330 20:23:40 * celticminstrel is not going to make any recommendations on whether or not to use threads in the first place.
20160330 20:24:07< celticminstrel> Was it mingw32 that was missing <thread>?
20160330 20:24:34< celticminstrel> If we don't need to support the MinGW that's missing <thread>, we can just use std::thread instead of boost::thread.
20160330 20:24:43< celticminstrel> But we need to be sure of this.
20160330 20:24:47< celticminstrel> Who else uses MinGW?
20160330 20:24:51< loonycyborg> no idea, but mingw-w64 fork has better support for newer features
20160330 20:24:56< celticminstrel> Vultraz, SigurdFD...
20160330 20:25:00< loonycyborg> me
20160330 20:25:16< gfgtdf> celticminstrel: are there advantages of std::thread over boost::thread ?
20160330 20:25:17< loonycyborg> I make official windows releases with it
20160330 20:25:35< celticminstrel> gfgtdf: If I recall correctly, they are almost identical, but boost::thread may have one or two extra bits.
20160330 20:26:06< celticminstrel> loonycyborg: Oh right, you make the Windows builds, so do you know if we currently support Windows XP?
20160330 20:26:30< loonycyborg> yup, I make them by booting from my winxp partition
20160330 20:26:40< loonycyborg> to make sure it's still works there :P
20160330 20:26:55< celticminstrel> gfgtdf: In other words, no, there are no advantages of std::thread over boost::thread except of course the lack of an additional dependency.
20160330 20:27:17< celticminstrel> loonycyborg: So, is that also using mingw64 then? Or would using std::thread break that build?
20160330 20:27:48< loonycyborg> yup, I'm using mingww64 there
20160330 20:28:06< gfgtdf> celticminstrel: well i think think building another part of boost makes things harder if we already require some boost parts .
20160330 20:28:10< loonycyborg> sdl2 didn't work with baseline mingw32
20160330 20:28:21< loonycyborg> so it forced me to switch
20160330 20:28:51< loonycyborg> I think using std libs is advantageous because it can be optimized for particular compiler
20160330 20:28:58< celticminstrel> Okay, so I have two paragraphs in the email draft so far.
20160330 20:29:00< SigurdFD> I'm using mingww64 as well, I'm pretty sure using mingw32 on windows won't work anymore
20160330 20:29:05< celticminstrel> "We are moving towards allowing C++11 to be used in the Wesnoth codebase. Yesterday, the Travis was updated to build only for C++11, and a commit using C++11 lambdas was made in master. Over the next few days, certain simple C++11 features (such as nullptr) will be integrated into the code."
20160330 20:29:12< celticminstrel> "This unfortunately means dropping support for a few older systems. In particular, we can no longer support Mac OSX 10.6, as the C++11 standard library is not available prior to 10.7. We will be targeting GCC 4.7 and MSVC 12 (2013), so Linux distributions that ship with older GCC will no longer be supported, such as older versions of Arch Linux or OpenBSD. The full results of the research can be view at <>. On the other hand, suppor
20160330 20:29:13< celticminstrel> for Windows XP will probably be continued for now."
20160330 20:29:31< celticminstrel> Any comments? Other things I should mention? Corrections?
20160330 20:29:44< celticminstrel> Also, that <> will contain https://wiki.wesnoth.org/User:Celtic_Minstrel/WesnothCxx11Support
20160330 20:30:39< gfgtdf> hmm i wonder which version is msvc14 
20160330 20:30:46< gfgtdf> msvc13 i mean
20160330 20:30:55< celticminstrel> Good question!
20160330 20:31:02< celticminstrel> I haven't the slightest clue.
20160330 20:31:17< celticminstrel> Maybe they skipped it. That does happen sometimes.
20160330 20:31:18-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 276 seconds]
20160330 20:32:05< gfgtdf> celticminstrel: y mostlikely they didnt liek the number 13
20160330 20:32:15< celticminstrel> That's a possibility.
20160330 20:32:59-!- SigurdFireDragon [~SigurdFD@dynamic-acs-72-23-176-151.zoominternet.net] has joined #wesnoth-dev
20160330 20:33:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 20:33:16-!- SigurdFD [~SigurdFD@dynamic-acs-72-23-176-151.zoominternet.net] has quit [Ping timeout: 240 seconds]
20160330 20:33:17< loonycyborg> ugh but it's totally backwards way of doing things, doing the ml AFTER commits that force C++0x
20160330 20:33:34< celticminstrel> That was a mistake, yes.
20160330 20:33:58< celticminstrel> We were talking about not making the C++11 changes immediately, but then gfgtdf pushed his loading screen update.
20160330 20:34:32< gfgtdf> celticminstrel: well in my takl with vultraz it seemed liek everyone agrred with that
20160330 20:34:56< celticminstrel> Maybe he wasn't paying attention to our discussion where talked about waiting a day or two before C++11 changes.
20160330 20:35:19< celticminstrel> It's a mistake, but we can't really do anything about it now.
20160330 20:35:21< gfgtdf> celticminstrel: its not that those changes rally require c++11 we can easiyl change it to use classic boost::bind
20160330 20:35:52< celticminstrel> Well, sure, it could be done, but in my opinion there's not much point when we're planning to go C++11 anyway.
20160330 20:35:53< gfgtdf> celticminstrel: well its some work, but its  posible
20160330 20:36:12< celticminstrel> Does no-one have comments on my email draft, then?
20160330 20:36:39< loonycyborg> seems fine to me
20160330 20:36:58< gfgtdf> no comments from me
20160330 20:37:25< celticminstrel> I don't really see anyone else active around now, except SigurdFireDragon I guess.
20160330 20:37:33< celticminstrel> So I guess I might as well just send this.
20160330 20:38:19< SigurdFireDragon> no comments.
20160330 20:38:57-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 20:38:58< travis-ci> wesnoth/wesnoth#9117 (master - acc752a : Celtic Minstrel): The build is still failing.
20160330 20:38:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119634885
20160330 20:38:58-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 20:39:25< loonycyborg> celticminstrel: so scons should always use -std=c++11 now?
20160330 20:39:41< celticminstrel> Good, Travis is no longer spammed with WML test failures when compilation fails.
20160330 20:39:47< celticminstrel> loonycyborg: Yes.
20160330 20:40:02< SigurdFireDragon> did the loadscreen changes accidentally add a new depenency?
20160330 20:40:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 20:40:29< celticminstrel> SigurdFireDragon: Yes, though it would (probably) be very simple to un-add that since std::thread is essentially identical to boost::thread.
20160330 20:41:11< celticminstrel> If supporting MinGW that lacks <thread> is not an issue, we can go ahead and do that.
20160330 20:41:31< SigurdFireDragon> you mean the un-add?
20160330 20:41:37< celticminstrel> Yes.
20160330 20:41:52< celticminstrel> It sounds like it's probably not an issue, right? From what I understood during this conversation, it seems that the MinGW that lacks <thread> also doesn't work with SDL2, is that correct loonycyborg?
20160330 20:42:37< loonycyborg> I'm not sure about it. I'll check for sure later if mingw-w64 provides it
20160330 20:43:26< celticminstrel> Okay, ML post sent.
20160330 20:45:32-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160330 20:46:23< ancestral> celticminstrel: Dropping 10.6 support is probably fine. Basically, Macs that are 10 years old will be left out
20160330 20:46:46< celticminstrel> Not all 10-year-old Macs. Mine is 10 years old.
20160330 20:46:51< celticminstrel> But most, yes.
20160330 20:47:40< ancestral> There’s a MacBook Pro from 2007 that can run 10.11
20160330 20:48:03< ancestral> Yeah, the non-64-bit enabled Macs
20160330 20:48:16< ancestral> celticminstrel: Are you running 10.7 or something newer?
20160330 20:48:27< celticminstrel> 10.7
20160330 20:48:56< celticminstrel> Bah. I seem to have broken the XCode project...
20160330 20:49:04< celticminstrel> It builds but will not run.
20160330 20:49:12< ancestral> So essentially, every Mac that could play Wesnoth now supports 64-bit apps. However, with 10.7, the 32-bit kernel is the default
20160330 20:49:39< ancestral> 10.8 initiated the everything is 64-bit all the time
20160330 20:49:44< celticminstrel> I'm not quite sure, but I think my Mac doesn't support the 64-bit kernel.
20160330 20:50:02< celticminstrel> It's a 64-bit processor and supports 64-bit apps, though.
20160330 20:50:05< ancestral> https://support.apple.com/en-us/HT3770
20160330 20:50:29-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160330 20:51:06< ancestral> https://support.apple.com/en-us/ht3773 
20160330 20:51:19< ancestral> Anyway, I should probably still build it as a 32-bit app
20160330 20:51:43< celticminstrel> Sure.
20160330 20:51:43< ancestral> Maybe 1.16 we’ll be brave and switch to 64-bit only
20160330 20:51:47< ancestral> We’ll see
20160330 20:52:25< celticminstrel> Hmm, since XCode refused, I tried launching Wesnoth from the Finder. It's not responding; it has an icon but no window.
20160330 20:52:36< ancestral> Give it a minute
20160330 20:52:48< ancestral> First time after a build sometimes it takes like a minute and a half
20160330 20:52:58< celticminstrel> Really? Why's this?
20160330 20:53:06< celticminstrel> Pretty sure it's been longer than that though.
20160330 20:53:11< ancestral> I’m not sure why; it could be a bug, or it could be doing first-time prep stuff
20160330 20:53:15< ancestral> Hmm
20160330 20:53:36< ancestral> You could always dump the Application Support/Wesnoth_1.13 folder
20160330 20:54:02< celticminstrel> Dump? Do you mean delete it?
20160330 20:54:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 20:54:06< ancestral> Yes
20160330 20:54:14< ancestral> Move/remove/delete/rename
20160330 20:54:18< ancestral> Any of those things
20160330 20:54:49< ancestral> (Remove and delete are probably synonymous in this context)
20160330 20:56:27< celticminstrel> Oh, there's the window.
20160330 20:57:00< celticminstrel> Loading screen is much better now, though it's a looping animation which I dislike. Still, better than nothing.
20160330 20:57:48< celticminstrel> So I just need to fix XCode thinking it can't be launched, and the linker warnings.
20160330 20:58:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 21:00:31< celticminstrel> I think the bar and the moving dots could be swapped.
20160330 21:01:32< gfgtdf> celticminstrel: fell free to change the animation to seomthing different, it was actualyl more to test whether such animations are possibl in general.
20160330 21:02:00< mattsc> ancestral: are you going to update the libraries for 10.11?
20160330 21:02:55-!- gfgtdf [~chatzilla@f054057118.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
20160330 21:02:56< ancestral> I need to fix the libraries so they link correctly.
20160330 21:03:15< celticminstrel> Is that related to my linker warnings?
20160330 21:03:21< mattsc> Yes, I got the linker error also.
20160330 21:03:22< ancestral> But aside from that, adding readline, are there other libs?
20160330 21:03:32< celticminstrel> mattsc: Error, not warning?
20160330 21:03:35< mattsc> The “yes” was for ancestral 
20160330 21:04:05< celticminstrel> ancestral: Boost unit tests. Possibly chrono, though it's possible the unit tests will use std::chrono instead if available.
20160330 21:04:06< ancestral> mattsc: If you were to install deps through MacPorts or Homebrew and place them appropriately it would work
20160330 21:04:16< ancestral> But not necessary if I fix the linking
20160330 21:04:39< celticminstrel> Oh, right, mattsc probably got the error stemming from the Boost libs being built against libstdc++.
20160330 21:04:44< mattsc> celticminstrel: they are errors
20160330 21:04:47< mattsc> right
20160330 21:05:01< mattsc> ancestral: I know, I just don’t have time to think about it right now.
20160330 21:05:13< ancestral> No problem
20160330 21:05:30< ancestral> My target is this weekend
20160330 21:05:47< mattsc> If it’s trivial, I can do it on the side.  If it’s any more than that, it’s just not going to happen in the next day or two.
20160330 21:06:44< mattsc> … and possibly not in the next 2 weeks, because I’ll start traveling again on Monday.
20160330 21:06:49< celticminstrel> What textdomain would make sense for loadscreen strings? Plain "wesnoth"?
20160330 21:07:20< celticminstrel> Oh, I suppose taking the one declared in the WML would be best - wesnoth-lib.
20160330 21:10:06< celticminstrel> I see it's also declared in the source.
20160330 21:11:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 21:12:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 21:14:32-!- ziro_ [026855cc@gateway/web/freenode/ip.2.104.85.204] has quit [Ping timeout: 250 seconds]
20160330 21:15:50< celticminstrel> I don't like the sound of commit 0360184.
20160330 21:20:20< SigurdFireDragon> celticminstrel, loonycyborg: https://wiki.qt.io/MinGW-64-bit 
20160330 21:21:18-!- Kwandulin [~Miranda@p200300760F191CBACCA43FF26338FB84.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160330 21:21:19< SigurdFireDragon> It appears that both my current and future compiled methods use the posix version, which looks to support std::thread
20160330 21:21:30-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 268 seconds]
20160330 21:23:29-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 21:24:23< celticminstrel> Okay. I'll see what other MinGW-users have to say first, though.
20160330 21:24:39-!- mjs-de [~mjs-de@x4db53e27.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20160330 21:25:20< SigurdFireDragon> ok
20160330 21:25:50< loonycyborg> which methods are those?
20160330 21:26:25< SigurdFireDragon> current: https://forums.wesnoth.org/viewtopic.php?f=5&t=40694
20160330 21:26:51< SigurdFireDragon> future: https://github.com/wesnoth/wesnoth/pull/616
20160330 21:27:32< loonycyborg> ah yes thought as much :P
20160330 21:30:20 * celticminstrel currently waiting on vultraz and loonycyborg about <thread>
20160330 21:30:59-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 21:31:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160330 21:31:57< celticminstrel> Huh? I didn't change anything, and yet XCode isn't complaining about running it anymore.
20160330 21:32:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 21:32:26< celticminstrel> I guess that means just the linker visibility warnings need fixing.
20160330 21:33:17-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has quit [Remote host closed the connection]
20160330 21:33:57< celticminstrel> I'm not sure what OpenMP is, but I might've accidentally disabled it in the XCode project.
20160330 21:34:24< celticminstrel> There was an unknown setting that had OPEN_MP or something in the name.
20160330 21:35:03< celticminstrel> And I deleted all the unknown settings.
20160330 21:35:30< celticminstrel> Since the majority of them were outdated things, even including at least one applying to PPC processors.
20160330 21:36:31< loonycyborg> celticminstrel: I'm going to add check for boost::thread to scons for now
20160330 21:36:43< celticminstrel> Okay, sure.
20160330 21:36:49-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160330 21:36:56< celticminstrel> It's easy to remove it if we later decide on std::thread, after all.
20160330 21:37:02< loonycyborg> yup
20160330 21:37:24< loonycyborg> I tried to changed it to std::thread first, but it requires non-trivial amount of work
20160330 21:37:37< celticminstrel> (Probably easier to remove than add, since when removing you can just search for what you're removing, whereas when adding you need to figure out where to add it.)
20160330 21:41:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 21:47:26< irker509> wesnoth: loonycyborg wesnoth:master 0795ad879bf1 / SConstruct: scons: due to switch to std c++11 always pass -std=c++11 https://github.com/wesnoth/wesnoth/commit/0795ad879bf120684e2afc763fd9976e9ce34c17
20160330 21:47:28< irker509> wesnoth: loonycyborg wesnoth:master af7286c4214f / SConstruct: scons: add check for boost.thread since it's a dependency now https://github.com/wesnoth/wesnoth/commit/af7286c4214fc6770de2b1dcdb8bf99a1016ac94
20160330 21:49:45< SigurdFireDragon> will there be a mailing list announcement for the new depenency?
20160330 21:50:42< celticminstrel> That's a good point. Do you think we should announce the possibility and see if there's discussion?
20160330 21:51:02< celticminstrel> The alternative would be to first decide whether to switch it to std::thread, then announce if we decide not to.
20160330 21:51:47< loonycyborg> yup we need to try to switch to std::thread first
20160330 21:52:02< celticminstrel> So, don't announce until it's certain?
20160330 21:52:10< loonycyborg> yup
20160330 21:52:13-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 21:52:14< travis-ci> wesnoth/wesnoth#9118 (master - af7286c : loonycyborg): The build is still failing.
20160330 21:52:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119659161
20160330 21:52:14-!- travis-ci [~travis-ci@ec2-54-162-58-90.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 21:52:18< celticminstrel> Okay.
20160330 21:52:41< SigurdFireDragon> https://wiki.wesnoth.org/DeveloperGuide says there should be a message to the mailing list first before adding dependencies
20160330 21:52:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160330 21:53:04< celticminstrel> Does anyone know whether there is a way to make Travis use GCC 4.7 instead of GCC 4.8?
20160330 21:53:50< celticminstrel> The wiki page seems to contradict loonycyborg's opinion...
20160330 21:54:17< loonycyborg> we still need to know if we actually add this dependency
20160330 21:55:06< loonycyborg> the key work here is BEFORE, not AFTER
20160330 21:55:32< celticminstrel> Key word?
20160330 21:55:55< loonycyborg> yup, the most important part :P
20160330 21:56:15< celticminstrel> I actually thought Boost.Thread was already a dependency; it was already listed in the XCode project.
20160330 21:56:43< loonycyborg> it's strictly speaking isn't even a separate dependency
20160330 21:56:47< celticminstrel> So, what's wrong with Travis now...
20160330 21:56:54< loonycyborg> we depend on boost and that's the only thing that matters
20160330 21:57:03< loonycyborg> travis doesn't install boost-thread
20160330 21:57:09< celticminstrel> Ah, missing ... yeah that.
20160330 21:57:49< celticminstrel> Should I fix it? Or, again, should I wait until we're sure?
20160330 21:58:51-!- prkc [~prkc@46.166.138.167] has quit [Ping timeout: 246 seconds]
20160330 22:00:43< irker509> wesnoth: loonycyborg wesnoth:master f962431710e1 / .travis.yml: travis: install boost.thread too https://github.com/wesnoth/wesnoth/commit/f962431710e1e036407319cd8ee2cfb464b13344
20160330 22:03:53< celticminstrel> I can't find anything about requesting a specific GCC version on Travis. :(
20160330 22:04:14-!- Appleman1234 [~Appleman1@KD106161151082.au-net.ne.jp] has quit [Ping timeout: 248 seconds]
20160330 22:04:19< celticminstrel> I suppose one could always use the install stage to do it, but...
20160330 22:06:09< celticminstrel> I feel like this could be relevant? https://jonasw.de/blog/2015/07/22/develop/cplusplus14-on-travis-with-cmake/
20160330 22:06:56< celticminstrel> And by extension, https://docs.travis-ci.com/user/installing-dependencies/
20160330 22:07:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 22:08:17< vultraz> celticminstrel: I was going to get to the ml post myse;f, but thank you for doing it first
20160330 22:09:15 * vultraz switches back to boost 1.58
20160330 22:11:04< celticminstrel> I think that's probably what I'm using now, too.
20160330 22:11:39< vultraz> I simply cannot get 1.60 to work for the life of me
20160330 22:11:56< celticminstrel> I might be using 1.59.
20160330 22:12:12< vultraz> Turns out there's no 'c++11' mode for boost, so I just have to silence the warnings about auto_ptr
20160330 22:12:22< celticminstrel> No, don't do that.
20160330 22:12:36< celticminstrel> ...wait, are the warnings in Boost? I thought they were in GUI2.
20160330 22:12:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 22:12:41< vultraz> in boost
20160330 22:12:47< loonycyborg> maybe swap auto_ptr for unique_ptr?
20160330 22:12:59< celticminstrel> I'm pretty sure the ones I saw SigurdFireDragon post were in GUI2 though...
20160330 22:13:01< vultraz> I'm not going to edit boost :P
20160330 22:13:10< loonycyborg> oh it's from boost
20160330 22:13:27< celticminstrel> vultraz: If possible, silence only warnings from Boost itself.
20160330 22:13:40< vultraz> I added -Wno-deprecated-definitions 
20160330 22:13:42-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has joined #wesnoth-dev
20160330 22:13:49< celticminstrel> vultraz: However, there are also quite a few auto_ptr instanves in the Wesnoth source.
20160330 22:13:55< celticminstrel> ^instances
20160330 22:13:56< loonycyborg> yes
20160330 22:14:06< loonycyborg> there are direct auto_ptr uses in wesnoth
20160330 22:14:21< vultraz> 16
20160330 22:14:26< loonycyborg> uses in boost are suppressed for me due to using -isystem
20160330 22:14:29< celticminstrel> vultraz: So those can be replaced with unique_ptr.
20160330 22:14:37< vultraz> 2 of which are comments
20160330 22:14:44< celticminstrel> See if that fixes the warnings without -Wno-whatever.
20160330 22:14:48-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 22:15:02< celticminstrel> (Either std::unique_ptr or boost::unique_ptr)
20160330 22:15:06< vultraz> celticminstrel: drop-in replacements?
20160330 22:15:20< loonycyborg> no, they have different semantics
20160330 22:15:20< celticminstrel> I'm not quite sure, but probably?
20160330 22:15:31< loonycyborg> should be mostly the same
20160330 22:15:41< vultraz> I know they have different uses, but I was referring to our usecases
20160330 22:15:43< loonycyborg> unique_ptr is non-copyable but movable
20160330 22:16:00< celticminstrel> They should be replaced with either unique_ptr or shared_ptr.
20160330 22:17:07< vultraz> I'll see if unique_ptr works
20160330 22:17:28< vultraz> Let me check out the new loadscreen and I have a small build fix commit to push
20160330 22:18:47< vultraz> celticminstrel: so can we begin pushing  the c++11 code changes, then?
20160330 22:18:55< celticminstrel> "error gui/parse: horizontal_grow and horizontal_alignment can't be combined, alignment is ignored"
20160330 22:19:06< vultraz> yeah that's standard
20160330 22:19:25< celticminstrel> vultraz: I probably would've recommended waiting another day, but since we've already got gfgtdf's lambdas, I suppose we can go ahead with C++11 changes.
20160330 22:19:32< vultraz> yay!
20160330 22:19:40< celticminstrel> It's not standard, it's an error that needs fixing!
20160330 22:19:57< vultraz> wait, is that in travis?
20160330 22:20:09< celticminstrel> I dunno, but it's on my build.
20160330 22:20:19< vultraz> I think I know what added it
20160330 22:20:20< celticminstrel> Travis hasn't finished yet, seemingly.
20160330 22:20:22< vultraz> I'll take a look
20160330 22:20:27< vultraz> give me a few minutes
20160330 22:20:52< vultraz> yup
20160330 22:20:58< vultraz> will commit fix
20160330 22:21:13-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160330 22:21:19< celticminstrel> I'm not too happy with the current animation; thinking of ways to improve it.
20160330 22:21:30< vultraz> I haven't even seen it yet
20160330 22:21:52< celticminstrel> Maybe we can leave it like this for 1.13.5 though. It's not terrible, and certainly better than nothing.
20160330 22:21:53< vultraz> I was building, got errors since I needed to enable c++11, then decided to try to build boost, realized I didn't need to build boost..
20160330 22:22:06< celticminstrel> We do need to fix stage names not being translatable, though. That might be a bit difficult.
20160330 22:24:47< celticminstrel> Okay, I have a Travis update, let's see if this works...
20160330 22:26:01-!- SigurdFireDragon [~SigurdFD@dynamic-acs-72-23-176-151.zoominternet.net] has quit []
20160330 22:26:58< celticminstrel> I think it would be good to switch the Travis config to use the apt add-on, but getting it to not fail is more important.
20160330 22:27:09-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 248 seconds]
20160330 22:28:18< celticminstrel> And making sure it's building on the compiler version that we want to officially target.
20160330 22:30:54< vultraz> oh, hey
20160330 22:31:33< vultraz> animation!
20160330 22:31:35< vultraz> :D
20160330 22:31:56< loonycyborg> celticminstrel: I only know how to switch between compiler versions on gentoo, unfortunately travis seems to use ubutu :P
20160330 22:32:05< loonycyborg> *ubuntu
20160330 22:32:15-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160330 22:32:31< celticminstrel> I would expect it to be similar.
20160330 22:32:46< loonycyborg> I would not
20160330 22:32:58< celticminstrel> I dunno.
20160330 22:33:00< loonycyborg> becuase on gentoo it's called by specific tool
20160330 22:33:05< loonycyborg> gcc-config
20160330 22:33:11< celticminstrel> Ah.
20160330 22:33:13< loonycyborg> that is part of gentoo's own tools
20160330 22:33:37< loonycyborg> debian has alternatives system but not sure if it can be used for compiler versions
20160330 22:35:01< vultraz> ugh how do you possibly disable warnings just from boost..
20160330 22:35:18< celticminstrel> vultraz: -isystem instead of -I
20160330 22:36:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160330 22:37:34< irker509> wesnoth: Charles Dang wesnoth:master b98687147a86 / src/log_windows.hpp: Fixup compilation on C++11 https://github.com/wesnoth/wesnoth/commit/b98687147a864ced74a46b7d5dc02bd11c321af1
20160330 22:37:37< irker509> wesnoth: Charles Dang wesnoth:master 38223569ab05 / src/units/filter.cpp: Removed unnecessary boost include https://github.com/wesnoth/wesnoth/commit/38223569ab0563977aa6e393f55c6d12dfceb7bd
20160330 22:37:40< irker509> wesnoth: Charles Dang wesnoth:master 1f52abcbfb7b / data/gui/window/loadscreen.cfg: tloadscreen: fix conflicting alignment keys in animation label https://github.com/wesnoth/wesnoth/commit/1f52abcbfb7b90bed9af287cb3eedc02b136055e
20160330 22:37:43< irker509> wesnoth: Charles Dang wesnoth:master c97a5d14ffec / projectfiles/CodeBlocks/ (liblua.cbp wesnoth.cbp wesnothd.cbp): Codeblocks: enable building with c++11 https://github.com/wesnoth/wesnoth/commit/c97a5d14ffec909d73346c183ed8d2b5bf46e5f2
20160330 22:41:10< vultraz> celticminstrel: seems in our usecases, unique_ptr is a drop-in replacement
20160330 22:41:14< vultraz> should I commit?
20160330 22:41:22< celticminstrel> Hold on a second.
20160330 22:41:33< celticminstrel> Yes, but I'm about to push.
20160330 22:41:51< irker509> wesnoth: Celtic Minstrel wesnoth:master 3eb45c6b2cdc / .travis.yml: Travis: Force GCC version 4.7 https://github.com/wesnoth/wesnoth/commit/3eb45c6b2cdccb744d7061d047e66c37afbbb70f
20160330 22:42:04< celticminstrel> Can we cancel older Travis builds?
20160330 22:42:23< vultraz> dunno
20160330 22:42:35< celticminstrel> The build for adding the Thread dependency hasn't shown its result though...
20160330 22:42:44< celticminstrel> That's probably the most important one...
20160330 22:43:39< celticminstrel> Hmm, it failed in one case and errored in one case, and the other case is still going...
20160330 22:43:51< vultraz> will push now
20160330 22:44:15< celticminstrel> Ah, it's a unit test failure.
20160330 22:44:18< irker509> wesnoth: Charles Dang wesnoth:master f849048a426f / src/ (8 files in 5 dirs): Use unique_ptr instead of auto_ptr (deprecated in c++11) https://github.com/wesnoth/wesnoth/commit/f849048a426fcb08b8a1c0be30d300e799a250b8
20160330 22:44:42< celticminstrel> vultraz: Please add loadscreen to the unit tests.
20160330 22:45:11-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 22:45:12< travis-ci> wesnoth/wesnoth#9119 (master - f962431 : loonycyborg): The build has errored.
20160330 22:45:12< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119662303
20160330 22:45:12-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 22:45:17< celticminstrel> The game_load window is failing.
20160330 22:45:35< celticminstrel> Also mp_change_control.
20160330 22:45:40< celticminstrel> Both related to listboxes.
20160330 22:45:41-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160330 22:47:03< vultraz> i never know if I'm supposed to add a dedicated tweapper template for a new test..
20160330 22:47:11< celticminstrel> I don't even know what's up with the optimized build.
20160330 22:47:42< celticminstrel> The C++ unit tests work, but the WML unit tests can't find the executable.
20160330 22:48:05< celticminstrel> Actually, I think the latter is the case in all three of them...
20160330 22:49:47< irker509> wesnoth: Charles Dang wesnoth:master 531f391ad8bc / src/tests/gui/test_gui2.cpp: Exclude loadscreen from GUI2 tests https://github.com/wesnoth/wesnoth/commit/531f391ad8bc29c8d2b233cf33735fd79a1edf29
20160330 22:51:38< celticminstrel> Excluding isn't what I meant, but whatever...
20160330 22:52:23< mattsc> ancestral, celticminstrel: I had forgotten that I don’t need to change the internal links to other libraries for my local build, so it was indeed trivial to build the boost libraries with Macports and bind them in.
20160330 22:52:42< mattsc> I’m getting 224 warnings now, but I am going to ignore those for now.
20160330 22:52:51< celticminstrel> Yeah, that's pretty much what I did.
20160330 22:53:00< celticminstrel> Compiler warnings or linker warnings?
20160330 22:53:10< mattsc> compiler warnings
20160330 22:53:19< celticminstrel> No linker warnings?
20160330 22:53:36< mattsc> “overrides a member function but is not marked 'override’”
20160330 22:53:55< celticminstrel> Oh, fun.
20160330 22:53:56< mattsc> Oh, I was wrong.  2029 warnings!
20160330 22:54:06< celticminstrel> Whoooa.
20160330 22:54:22< celticminstrel> That's insane.
20160330 22:54:30< celticminstrel> Any others besides override?
20160330 22:54:39< mattsc> No, on quick look it doesn’t look like there are linker warnings, but I am not going to read all 2000 of them.
20160330 22:55:02< celticminstrel> They'd probably be at the bottom.
20160330 22:55:04< mattsc> No, that seems to be it (with the same caveat)
20160330 22:55:16< mattsc> Right, that’s where I looked.
20160330 22:55:21< celticminstrel> Ah, okay.
20160330 22:55:38< mattsc> Anyways, it compiles and runs and that’s all I have time for at the moment.
20160330 22:55:40< celticminstrel> It's probably a difference in your Boost libs, then.
20160330 22:55:50< celticminstrel> Or something.
20160330 22:56:39< mattsc> It might also be that I have a local copy of, say, gettext in the project file, but the boost libs I just compiled refer to the one in the Macports build.  Something like that.
20160330 22:56:58< celticminstrel> Setting "Symbols Hidden by Default" to NO seems to fix it for me, but that might just cause it for you, so I guess I won't commit that.
20160330 22:57:00< mattsc> I’m sure I can work it out, just can’t pay attention to it right now.
20160330 22:57:28< mattsc> For now I am happy that I have a working build.
20160330 22:57:37< celticminstrel> My Boost libs are ones that I compiled myself, anyway.
20160330 22:57:45< mattsc> So are mine.
20160330 22:58:12< celticminstrel> I see.
20160330 22:58:50< vultraz> loadscreen appears as soon as I click Campaigns :/
20160330 22:59:10-!- mjs-de [~mjs-de@x4db53e27.dyn.telefonica.de] has joined #wesnoth-dev
20160330 22:59:16< celticminstrel> Looks like my GCC 4.7 thing did not work.
20160330 22:59:27< vultraz> celticminstrel: for the loadscreen, do you prefer the components further apart for closer together, vertically
20160330 22:59:35< celticminstrel> Oh wait, maybe it did work.
20160330 22:59:39< celticminstrel> Yeah okay, it does work.
20160330 23:00:00-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160330 23:00:12< celticminstrel> It's just that Travis first prints the version of the official one.
20160330 23:01:10-!- Appleman1234 [~Appleman1@KD106161153139.au-net.ne.jp] has joined #wesnoth-dev
20160330 23:05:15-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has quit [Ping timeout: 264 seconds]
20160330 23:06:20< vultraz> testing the to_string() change
20160330 23:07:17-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 23:07:18< travis-ci> wesnoth/wesnoth#9120 (master - c97a5d1 : Charles Dang): The build has errored.
20160330 23:07:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119669516
20160330 23:07:18-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 23:07:40-!- gfgtdf [~chatzilla@f054057118.adsl.alicedsl.de] has joined #wesnoth-dev
20160330 23:07:49< vultraz> I'm going to remove str_cast, but not lexical_cast<std::string> (yet)
20160330 23:08:23< gfgtdf> mattsc: you coudl eigher add hat wanring to the ignorelist or add override to all those functions.
20160330 23:08:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20160330 23:08:54< vultraz> gfgtdf: did you make the widgets on the loadscreen further apart vertically?
20160330 23:09:27< gfgtdf> vultraz: hmm i made the spacers at top and bottom smaller becasue it didnt work for small resolutions otherwise
20160330 23:09:39< vultraz> ahh
20160330 23:11:13< gfgtdf> celticminstrel: whats the intention for forcing version 4.7 on travis ?
20160330 23:11:57< celticminstrel> gfgtdf: Because in the ML post I said we'll be targeting 4.7, so this means that we can easily see if we accidentally add something that 4.7 doesn't support.
20160330 23:12:31< vultraz> celticminstrel: is this a valid formula: height = "((screen_height - (if(screen_height < 800, 400, 0)) / 4)"
20160330 23:12:45< celticminstrel> Geh, parsing.
20160330 23:13:12< celticminstrel> One moment while I copy it into TextWrangler so I can see where the brackets balance.
20160330 23:14:13< celticminstrel> vultraz: Looks fine to me.
20160330 23:14:29< celticminstrel> The parentheses around the if are extraneous.
20160330 23:14:52< gfgtdf> celticminstrel: hmm with gcc 4.7 it seems like we cannot use inheriting construcotrs, (just like with msvc 2013)
20160330 23:14:58< celticminstrel> I think we really need to prioritize fixing the Travis build.
20160330 23:15:17< celticminstrel> gfgtdf: Yes, that's right.
20160330 23:15:29< gfgtdf> celticminstrel: thats quite annyoing
20160330 23:15:55< gfgtdf> celticminstrel: doe we have any devepolers that cannot update to gcc4.9 or msvc 2015 ?
20160330 23:16:08< celticminstrel> gfgtdf: It's not about devs in this case.
20160330 23:16:30< gfgtdf> celticminstrel: about what then ?
20160330 23:16:36< celticminstrel> Linux distros.
20160330 23:17:01< gfgtdf> celticminstrel: can't those user just install newer compilers ?
20160330 23:17:06< celticminstrel> We also can't use the restricted unions I wanted in the formula variant. Can't remember if that was due to MSVC 2013 or GCC 4.7, though.
20160330 23:17:35< celticminstrel> gfgtdf: Well, sure they can, if they want to build it themselves, but I don't think an official package would want to do that.
20160330 23:17:48-!- prkc [~prkc@192.40.89.17] has joined #wesnoth-dev
20160330 23:17:57< gfgtdf> celticminstrel: do we have official packages ?
20160330 23:18:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160330 23:19:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160330 23:21:39-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 248 seconds]
20160330 23:22:21< gfgtdf> celticminstrel: or rather: what do you mean back packages wanting things.
20160330 23:24:06< vultraz> celticminstrel: blah. seems to_string() isn't a drop-in replacement in all cases
20160330 23:24:25< celticminstrel> gfgtdf: Yes, for example https://packages.debian.org/stable/games/wesnoth and http://packages.ubuntu.com/trusty/games/wesnoth
20160330 23:24:33< celticminstrel> (Admittedly, both of those are still 1.10. :( )
20160330 23:24:45< vultraz> apparently str_cast/lexical_cast was used in some places with map_location or unit_type::ALIGNMENT arguments
20160330 23:24:46< vultraz> etc etc
20160330 23:24:59< celticminstrel> vultraz: to_string should work with those, I thought?
20160330 23:25:04< gfgtdf> celticminstrel: then why do we care abouth those packages if they are for wesnoth 1.10 ?
20160330 23:25:09< vultraz> doesn;t
20160330 23:25:27< vultraz> get things such as
20160330 23:25:30< vultraz> C:\TDM-GCC-32\lib\gcc\mingw32\5.1.0\include\c++\bits\basic_string.h|5294|note:   no known conversion for argument 1 from 'const game_classification::CAMPAIGN_TYPE' to 'int'|
20160330 23:25:32< celticminstrel> Oh, you're right, it's only for numbers. Okay then.
20160330 23:26:23< gfgtdf> vultraz: which line exactly do you want to change ?
20160330 23:27:39< vultraz> gfgtdf: I'm converting most cases of str_cast or lexical_cast<std::string> to std::to_string, but the latter can't handle types that aren't ints
20160330 23:27:45< vultraz> for example game_board.cpp:117
20160330 23:28:57< gfgtdf> vultraz: i think in that case you can just remove the lexical_cast and put the defeat_condition directly to the stream
20160330 23:28:58< celticminstrel> gfgtdf: For inheriting constructors specifically, we also still have devs on MSVC 2013.
20160330 23:29:09< gfgtdf> celticminstrel: who ?
20160330 23:29:12< celticminstrel> At least one major one.
20160330 23:29:14< celticminstrel> Zookeeper.
20160330 23:29:21< celticminstrel> If I recall correctly.
20160330 23:29:40< gfgtdf> celticminstrel: also we should mabe notz anymore shot with msvc9 projectfiles if the minium is 2013 or 2015
20160330 23:30:14< celticminstrel> Yes, we should update the MSVC project file. That should probably be done by someone with MSVC12, though.
20160330 23:30:21< celticminstrel> ie, not you
20160330 23:30:51< gfgtdf> good if i cannot do it :)
20160330 23:31:14< celticminstrel> I could do it, not sure I want to go to that trouble though...
20160330 23:31:23< celticminstrel> I'd prefer if zookeeper can do it.
20160330 23:31:25< gfgtdf> celticminstrel: i thought you're on mac ?
20160330 23:31:42< celticminstrel> Yes, but I also have a Windows computer sitting around with MSVC 2013 installed.
20160330 23:36:16 * vultraz should probably also use std::stoi where appropriate
20160330 23:36:24< celticminstrel> Meh.
20160330 23:36:41< celticminstrel> Given that to_string is only for numbers, I'm not so sure this change is worth it now.
20160330 23:36:57< celticminstrel> I mean, sure, feel free to use to_string for future code.
20160330 23:37:07< celticminstrel> But...
20160330 23:37:11< vultraz> I've already changed most of the cases locally
20160330 23:37:27< celticminstrel> There are some cases of atoi, I think, maybe look into replacing those with stoi.
20160330 23:37:44< vultraz> what's the difference?
20160330 23:38:25< celticminstrel> One takes const char*, the other takes std::string? I guess? I mean, if you're doing stoi anyway, you might as well cover that case.
20160330 23:38:40< celticminstrel> If you're not going to bother with stoi, then don't bother with it.
20160330 23:39:55-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160330 23:41:30-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 23:41:31< travis-ci> wesnoth/wesnoth#9123 (master - 531f391 : Charles Dang): The build has errored.
20160330 23:41:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119672009
20160330 23:41:31-!- travis-ci [~travis-ci@ec2-54-158-176-145.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 23:41:51 * vultraz is not sure why we use lexical_cast on MAKE_ENUM enums when MAKE_ENUM has its own string return member
20160330 23:42:03< celticminstrel> Why not?
20160330 23:42:33< celticminstrel> Using lexical_cast everywhere does mean it's the same syntax no matter what's being converted to what. There's something to be said for that, I think.
20160330 23:43:38< celticminstrel> Of course, we already have str_cast and possibly other methods, so we're not using lexical_cast everywhere anyway.
20160330 23:46:38< vultraz> ok, 13 cases of lexical_cast<std::string> remain
20160330 23:47:19< celticminstrel> Oh wow, David White replied to the mailing list.
20160330 23:47:20< gfgtdf> celticminstrel: well, at least in the current implementation, lexical_cast is slower and make_nums own conversion method
20160330 23:48:02< vultraz> you mean than?
20160330 23:48:25< gfgtdf> s/and/than
20160330 23:48:33< celticminstrel> I'm going to assume that everything the scons file lists as part of tests is in fact required for tests.
20160330 23:48:53< celticminstrel> It won't hurt to compile a few extra files for unit tests, anyway.
20160330 23:49:25< gfgtdf> vultraz: i think if good if you change those occurances ot use make_enums own to_string method.
20160330 23:49:31< vultraz> I'll try
20160330 23:50:02-!- travis-ci [~travis-ci@ec2-54-196-34-6.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 23:50:03< travis-ci> wesnoth/wesnoth#9121 (master - 3eb45c6 : Celtic Minstrel): The build has errored.
20160330 23:50:03< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119670499
20160330 23:50:03-!- travis-ci [~travis-ci@ec2-54-196-34-6.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 23:50:16< celticminstrel> We really need to fix the build...
20160330 23:50:34-!- travis-ci [~travis-ci@ec2-54-196-34-6.compute-1.amazonaws.com] has joined #wesnoth-dev
20160330 23:50:35< travis-ci> wesnoth/wesnoth#9122 (master - f849048 : Charles Dang): The build has errored.
20160330 23:50:35< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119670937
20160330 23:50:35-!- travis-ci [~travis-ci@ec2-54-196-34-6.compute-1.amazonaws.com] has left #wesnoth-dev []
20160330 23:51:15< gfgtdf> celticminstrel: is it stil failing for linker erros ?
20160330 23:51:50< celticminstrel> gfgtdf: No, I think it's unit tests now.
20160330 23:51:55< celticminstrel> At least, it was when I last looked.
20160330 23:57:52-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160330 23:58:19-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
--- Log closed Thu Mar 31 00:00:14 2016