--- Log opened Sun Jul 24 00:00:34 2016
20160724 00:00:43-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160724 00:01:29< ancestral> celmin: Around?
20160724 00:01:40< celmin> Kinda?
20160724 00:01:47< celmin> What's up?
20160724 00:02:41< ancestral> Trying to build master in OS X
20160724 00:02:51< celmin> Ah...
20160724 00:03:03< celmin> Guessing you're having problems?
20160724 00:03:15< ancestral> Yeah, but should be fixable
20160724 00:03:53< ancestral> I’m getting messages such as “use of undeclared identifier ‘nullptr_t’; did you mean ‘nullptr’?”
20160724 00:04:00< ancestral> Would that be boost it’s talking about?
20160724 00:04:08< celmin> Huh?
20160724 00:04:15-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160724 00:04:21< celmin> Well, if it's Boost, that should be clear from the error message.
20160724 00:04:29< ancestral> No member named ‘memcpy’ in namespace ‘std::__1’ did you mean simply ‘memcpy’?
20160724 00:05:02< celmin> I think that should be fixed by including <cstdlib> instead of <stdlib.h>.
20160724 00:05:32< ancestral> Hmm, so it’s pulling from Xcode toolchain
20160724 00:05:37< celmin> nullptr_t is in the std namespace.
20160724 00:05:46< ancestral> Okay, so cstdlib?
20160724 00:05:49< celmin> And apparently declared in <cstdlib> as well, I think.
20160724 00:06:14< ancestral> Where does that get defined, do you know?
20160724 00:06:20< celmin> Hm?
20160724 00:06:34< celmin> Where does what get defined?
20160724 00:06:49< ancestral> What file is calling stdlib.h that needs to be changed to cstdlib.h, or is it a build parameter that I need to change?
20160724 00:07:01< celmin> No .h
20160724 00:07:11< ancestral> Oh right
20160724 00:07:13< celmin> I have no idea what file it is. Usually the error message tells you this.
20160724 00:09:00< ancestral> Well, the errors are showing up here: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
20160724 00:09:18< celmin> Huh?
20160724 00:09:39< celmin> That path is the standard C++ library.
20160724 00:09:56< ancestral> Yes, so I am getting errors resulting from the project calling the standard C++ library
20160724 00:11:19< celmin> I'm completely lost now.
20160724 00:12:26< ancestral> celmin: http://uploadpie.com/7yEUW
20160724 00:14:37< Aginor> weird
20160724 00:14:50< ancestral> Maybe telling you what I did before this would help
20160724 00:15:14< celmin> What did you do before this?
20160724 00:15:23< ancestral> I had to drop in new boost libraries and headers and make sure the project has their paths, so I did that
20160724 00:15:39< ancestral> I had to download SDL2 and put those in there like the same
20160724 00:15:50< celmin> But SDL2 is already referenced by the project.
20160724 00:16:08< ancestral> In the Xcode project file?
20160724 00:16:11< celmin> Yes.
20160724 00:16:21< celmin> I've been building against SDL2 since the last release. Possibly before.
20160724 00:16:32< ancestral> Okay, so maybe I checked that and didn’t do it
20160724 00:16:41< ancestral> Alright
20160724 00:16:48< celmin> (It expects it to be in a weird place, admittedly - the lib/ folder next to the XCode project.)
20160724 00:17:01< ancestral> I had to change the SDK to latest (which should be fine, I don’t have the 10.7 SDK)
20160724 00:17:30< celmin> Hmm. I wonder if that'll break my compile… I do have the 10.8 SDK though for some reason...
20160724 00:17:38< ancestral> Oh, I had a different build of the SDL2 files, so yes, I had to because the extension is different — but I don’t think that’s causing this issue anyway
20160724 00:18:05< ancestral> From what mattsc or someone else was telling me, the latest SDK should work fine backwards, usually
20160724 00:18:05< celmin> Differeny extension?
20160724 00:18:09< celmin> Like dylib?
20160724 00:18:13< ancestral> .dylib
20160724 00:18:15< celmin> ^different
20160724 00:18:20< celmin> I see.
20160724 00:18:30< celmin> That's slightly annoying, but not a major problem.
20160724 00:18:36< ancestral> What else
20160724 00:18:49< ancestral> I had to add a header path as I got a types.h error
20160724 00:18:59< ancestral> Actually, I changed a path
20160724 00:19:00< celmin> Eh?
20160724 00:20:29< ancestral> Xcode/Headers/SDL/types.g
20160724 00:20:31< ancestral> *types.h
20160724 00:20:59< ancestral> So instead of adding ./Headers/SDL to the header search path I figure why not just make ./Headers/ recursive?
20160724 00:21:28< celmin> I wouldn't say that's the right answer… though I guess it works...
20160724 00:21:43< ancestral> I could instead add ./Headers/SDL I guess?
20160724 00:21:45< celmin> Oh, wait.
20160724 00:22:13< celmin> …wait, no, Boost always has .hpp so there's no way it could conflict with any standard headers, right?
20160724 00:22:34< celmin> Is there any reason why you don't use the frameworks version of SDL2?
20160724 00:22:54< ancestral> Wait
20160724 00:23:07< ancestral> celmin: There might not be
20160724 00:23:15< ancestral> I might be missing boost headers
20160724 00:23:21-!- RatArmy [~RatArmy@om126229088089.12.openmobile.ne.jp] has quit [Ping timeout: 258 seconds]
20160724 00:23:26< celmin> But yeah, adding ./Headers/SDL2/ is probably better then making ./Headers recursive if you really want the dylib version.
20160724 00:23:49< ancestral> Weird I thought I had them
20160724 00:24:02< celmin> (I haven't looked closely, but given that my build works I'm assuming SDL includes are like "SDL2/blah".)
20160724 00:24:30< celmin> Wait a second, if you include it like "SDL2/blah" then the SDL2 folder should not be in the header path, so you shouldn't need to add any paths at all.
20160724 00:24:43< ancestral> I can drop and start over if you like
20160724 00:25:06< ancestral> Might be prudent
20160724 00:25:12< celmin> I think it would be easier if you just use the frameworks. Then you wouldn't have to fiddle with the project quite as much.
20160724 00:26:16< ancestral> Okay
20160724 00:26:30< ancestral> Like the ones from the libsdl.org site?
20160724 00:26:54< celmin> That's where I got mine from.
20160724 00:28:39< ancestral> core, then mixer, image, net and ttf
20160724 00:28:51< celmin> I think you can skip net.
20160724 00:29:00< celmin> Only the campaign server still depends on it, and XCode isn't building that.
20160724 00:30:03< ancestral> Okay
20160724 00:30:13< ancestral> So Xcode/lib/ and it goes in there
20160724 00:30:29< celmin> Right, alongside all the Boost dylibs.
20160724 00:31:03-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20160724 00:31:05< ancestral> Where did you get your Boost dylibs?
20160724 00:31:25< ancestral> I have some built from Homebrew
20160724 00:31:56< celmin> I can't remember whether I'm still using the ones from the package on Sourceforge or if I substituted MacPorts or self-built ones.
20160724 00:32:00< ancestral> Okay
20160724 00:32:05< celmin> Sorry.
20160724 00:32:09< ancestral> No problem
20160724 00:32:36< ancestral> So Wesnoth previously used some with a different file name, and I think it was done that way to make it easier for otool or something
20160724 00:32:48< ancestral> libboost_filesystemw.dylib
20160724 00:33:09< celmin> Did that get removed?
20160724 00:33:17< ancestral> Should I rename the dylibs with w at the end, or put them in and change it in the Xcode project?
20160724 00:33:28< celmin> Oh, so it didn't.
20160724 00:33:35< ancestral> celmin: I am fairly certain that boost in the Mac Compile Stuff is OLD
20160724 00:33:38< ancestral> and will not build now
20160724 00:33:47< ancestral> I don’t know 100% though
20160724 00:33:50< celmin> Yeah, it was like 1.54 or something if I recall correctly.
20160724 00:34:01< ancestral> I have 1.60.0 built
20160724 00:34:11< celmin> I don't really understand why there's a W there, but personally I would prefer it gone.
20160724 00:34:11< ancestral> So I see regular and mt (multi-threaded?)
20160724 00:34:18< ancestral> Right
20160724 00:34:28< celmin> The best way to change it is to use the files tab in the right sidebar.
20160724 00:34:35-!- gfgtdf [~chatzilla@x4e36a461.dyn.telefonica.de] has joined #wesnoth-dev
20160724 00:34:37< celmin> Rather than deleting and re-adding the files.
20160724 00:34:42< celmin> (In my opinion, at least.)
20160724 00:35:01< gfgtdf> it seems like helper.rand cannot be used with tstring userdata objects anymore
20160724 00:35:11< ancestral> Files tab int the right sidebar
20160724 00:35:20< celmin> gfgtdf: Add a tostring() call to the implementation?
20160724 00:36:06< gfgtdf> celmin: hmm but it seesm like it also accept tables now so its not that easy.
20160724 00:36:09< celmin> ancestral: The one that tells you where on disk the currently selected file is and offers you a chance to point the alias elsewhere.
20160724 00:36:20< celmin> gfgtdf: I don't see the problem here?
20160724 00:36:34< ancestral> You’re talking about in Xcode?
20160724 00:36:35< celmin> gfgtdf: Obviously you call tostring() only if it's not a table.
20160724 00:36:48< ancestral> Oh I think I see it
20160724 00:37:02< celmin> ancestral: Yes, in XCode, but I'm admittedly assuming that the functionality still hasn't changed much from XCode 4...
20160724 00:37:15< ancestral> Okay so am I using the multi-threaded dylib or the non-mt
20160724 00:37:32< celmin> Uhh… I don't really understand why non-mt ones even exist.
20160724 00:37:40< ancestral> libboost_filesystem-mt.dylib vs. libboost_filesystem.dylib
20160724 00:37:48< ancestral> Yeah, it would seem like -mt is preferred
20160724 00:39:54< ancestral> Thanks for telling me about the info tab alias thing
20160724 00:40:03< ancestral> Never knew about that
20160724 00:40:31-!- gfgtdf [~chatzilla@x4e36a461.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160724 00:40:46< celmin> I said "alias" because it feels like XCode's file references are a bit like aliases, but that's probably a misapplication of the word. >_>
20160724 00:40:58< ancestral> I got what you meant
20160724 00:43:30< ancestral> Okay, I have all the libs from Mac Compile Stuff, except newer boot dylibs, newer SDL2 dylibs (and no SDL1 ones), and everything is linked to the new version
20160724 00:43:33< ancestral> And the readline lib
20160724 00:43:50< ancestral> No in the project, no red lines for libs
20160724 00:44:01< ancestral> (nothing missing, presumably)
20160724 00:44:20< ancestral> Okay, I need to drop the boost headers in
20160724 00:45:11< ancestral> So Headers/Boost
20160724 00:45:31< ancestral> (lowercase b)
20160724 00:45:43< celmin> I was about to mention that too.
20160724 00:46:15< ancestral> Okay
20160724 00:46:27< ancestral> Clean and Build
20160724 00:46:38< ancestral> wesnothd: arg.hpp
20160724 00:47:07< ancestral>  /Users/xxxx/Documents/Pilot/wesnoth 1.13/projectfiles/Xcode/Headers/boost/bind/arg.hpp:37:9: Static_assert failed "I == is_placeholder<T>::value"
20160724 00:48:01< ancestral> But maybe this is because I need to add the Boost header search path to the project?
20160724 00:48:32< ancestral>  ./Headers  ./Headers/glib-2.0  ./Headers/cairo
20160724 00:48:37< ancestral> But nothing for boost
20160724 00:49:11< ancestral> And it says non-recursive (that is what I tried changing earlier); so I should add ./Headers/boost to this list
20160724 00:49:48< celmin> Uhh....
20160724 00:49:54< celmin> No...
20160724 00:49:56< ancestral> No?
20160724 00:50:15< celmin> Because Boost headers are included as <boost/blah>, you only need the folder containing the boost folder to be in the path.
20160724 00:50:17< ancestral> Okay, made no difference
20160724 00:50:20< ancestral> Okay
20160724 00:50:33< ancestral> Removed that then
20160724 00:50:58< celmin> Try clicking the disclosure triangle by the error. It should give you more info.
20160724 00:51:44< ancestral> Lotta stuff…
20160724 00:52:13< ancestral> instantiation of template classes
20160724 00:52:14< ancestral> http://uploadpie.com/mqBul
20160724 00:55:21< celmin> What's the first one on that list? It looks like it's in Wesnoth code.
20160724 00:55:30< celmin> As is the second, come to think of it...
20160724 00:55:57< ancestral> src/server/ban.cpp:26
20160724 00:56:08< ancestral> src/utils/functional.hpp:23
20160724 00:56:16< ancestral> Headers/boost/bind.hpp:22
20160724 00:56:53< ancestral> Stuff like: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__tuple:291:14: In instantiation of template class 'std::__1::__tuple_convertible_apply<true, std::__1::tuple<const std::__1::tuple<boost::arg<1> > &>, std::__1::__tuple_types<boost::arg<1> > >' requested here
20160724 00:57:00< celmin> And the line of code?
20160724 00:57:09< ancestral> Okay, let’s see ban.cpp
20160724 00:57:16< ancestral> #include "utils/functional.hpp"
20160724 00:57:19< ancestral> ^
20160724 00:57:26< celmin> Ah, wrong one, hmm.
20160724 00:57:36< ancestral> This is functional.hpp:23
20160724 00:57:37< ancestral> #include <boost/bind.hpp> // Because std::bind is just not flexible enough
20160724 00:57:44< celmin> Try the "While substituting" ones.
20160724 00:58:04< ancestral>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/tuple:498:29: While substituting deduced template arguments into function template 'tuple' [with _Up = <const std::__1::tuple<boost::arg<1> > &>, $1 = (no value)]
20160724 00:58:07< celmin> Find a line in one of those two files.
20160724 00:58:29< ancestral>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/tuple:396:14: In instantiation of template class 'std::__1::__tuple_leaf<0, std::__1::__bind<wesnothd::banned *(boost::shared_ptr<wesnothd::banned>::*)() const, const boost::arg<1> &>, false>' requested here
20160724 00:58:57< celmin> Hmm, why is it making a tuple of boost::arg...
20160724 00:59:00< ancestral>  /Users/xxxx/Documents/Pilot/wesnoth 1.13/src/server/ban.cpp:553:66: In instantiation of template class 'std::__1::__bind<bool (wesnothd::banned::*)(const std::__1::basic_string<char> &) const, std::__1::__bind<wesnothd::banned *(boost::shared_ptr<wesnothd::banned>::*)() const, const boost::arg<1> &>, const std::__1::basic_string<char> &>' requested here
20160724 00:59:18< celmin> What's the line of code in ban.cpp?
20160724 00:59:42< ancestral> Okay, so that was the last error/comment
20160724 00:59:57< ancestral> ban.cpp:553:		std::remove_copy_if(bans_.begin(), bans_.end(), temp_inserter, std::bind(&banned::match_group,std::bind(&banned_ptr::get,_1),group));
20160724 01:00:25< celmin> Hmm… wait, was this the only error?
20160724 01:01:07< ancestral> wesnothd 1 issue > arg.hpp > Static_assert failed "I == is_placeholder<T>::value"
20160724 01:01:39< ancestral> That’s the only issue, but I don’t know if maybe the build aborted once it found this issue?
20160724 01:02:05< celmin> Well, let's find out. Change _1 to std::placeholders::_1 and see if you get another similar error later.
20160724 01:02:51< ancestral> Okay
20160724 01:02:54< ancestral> Thanks
20160724 01:03:30< ancestral> Cleaned and Build and same error but… left off on a different line with _1
20160724 01:03:40< ancestral> ban_set::const_iterator ban = std::find_if(bans_.begin(), bans_.end(), std::bind(&banned::match_ip, std::bind(&banned_ptr::get, _1), pair));
20160724 01:03:52< ancestral> So change that one too? _1 → std::placeholders::_1
20160724 01:04:15< celmin> Ugh...
20160724 01:04:35< ancestral> It’s moving
20160724 01:04:47< ancestral> Things are working
20160724 01:05:16< celmin> If it's only those two instances that are a problem, then changing it seems fine, but if it's all instances… :|
20160724 01:05:29< ancestral> Crap okay same error, different place
20160724 01:05:34< ancestral> Maybe same thing
20160724 01:05:48< ancestral> std::function<void(std::map<std::string,aspect_ptr>&, const config&, std::string)> factory_aspects =
20160724 01:05:49< ancestral> 		std::bind(&ai::ai_composite::replace_aspect,*this,_1,_2,_3);
20160724 01:05:58< ancestral> Heh, _1 _2 and _3
20160724 01:06:37< ancestral> Changed, building again
20160724 01:06:58< ancestral> Okay, same kind of error, different line
20160724 01:07:07< ancestral>  /Users/xxxx/Documents/Pilot/wesnoth 1.13/projectfiles/Xcode/Headers/boost/bind/arg.hpp:37:9: Static_assert failed "I == is_placeholder<T>::value"
20160724 01:10:21-!- abruanese [~a@45.63.97.181] has joined #wesnoth-dev
20160724 01:10:22< ancestral> Not sure how to resolve that line. I’ve commented out the BOOST_STATIC_ASSERT, but probably a bad idea
20160724 01:11:00< ancestral> Compiling 70/530 source files
20160724 01:11:36< ancestral> Warning: /Users/xxxx/Documents/Pilot/wesnoth 1.13/src/dialogs.cpp:1200:9: Moving a local object in a return statement prevents copy elision
20160724 01:14:07< ancestral> 245/530
20160724 01:14:21< ancestral> Okay, error, but I think I know what it is
20160724 01:14:28< ancestral> I need the history lib
20160724 01:16:10< ancestral> rather, header file
20160724 01:18:12< ancestral> Dropped all the readline headers in
20160724 01:19:14< celmin> I don't like this _n --> std::placeholders::_n change BTW
20160724 01:21:01< ancestral> I can’t figure out why Xcode is barfing over the BOOST_STATIC_ASSERT, but it’s with arg.hpp still
20160724 01:21:29< ancestral> Warning: /Users/xxxx/Documents/Pilot/wesnoth 1.13/src/game_initialization/multiplayer.cpp:151:11: Moving a local object in a return statement prevents copy elision
20160724 01:21:46< ancestral> 420/530
20160724 01:24:05< ancestral>  /Users/xxxx/Documents/Pilot/wesnoth 1.13/src/build_info.cpp:28:10: 'SDL_net.h' file not found
20160724 01:24:09< ancestral> Maybe I need net after all?
20160724 01:26:20< ancestral> Added SDL2_net.framework. Gotta rebuild everything.
20160724 01:30:46-!- trewe [~trewe@2001:8a0:d101:3801:a23c:e70e:3e7f:33eb] has quit [Quit: quit]
20160724 01:33:37< celmin> Supper callls, back after.
20160724 01:33:54< ancestral> celmin: Super thanks for your help! :)
20160724 01:45:17-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160724 01:56:57< celmin> :(
20160724 02:00:25-!- irker511 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160724 02:02:19< celmin> Don't go adding SDL_net back...
20160724 02:02:39< celmin> …what the heck is build_info.cpp anyway?
20160724 02:10:42-!- tad [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160724 02:11:05-!- tad is now known as Guest9655
20160724 02:15:28< Guest9655> I have two [side]s sharing the team_name 'allies' and would like the Status panel to show a different user_team_name for each. When I enter the scenario from the previous scenario, both show the user_side_name from the first side. But if I reload the scenario-start they show the different names I assigned. I am running on 1.13.4+dev synced a couple days ago. My question is: is this expected behavior, a bug, or am I missing so
20160724 02:16:07-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160724 02:16:36< celmin> Your post got cut off, FYI
20160724 02:16:46< ancestral> I dropped
20160724 02:16:46< celmin> "am I missing so" is how it appears to end
20160724 02:16:57< celmin> Though unless there's more after "something" I can tell what you meant.
20160724 02:17:00< Guest9655> My question is: is this expected behavior, a bug, or am I missing something or misunderstanding?
20160724 02:17:13< celmin> Just for clarity, that was not addressed to ancestral.
20160724 02:17:27< ancestral> Just got that now, thanks ;-)
20160724 02:17:32< celmin> Sounds like a bug.
20160724 02:17:54< celmin> Since you get different behaviour in two situations where you would expect the same behaviour.
20160724 02:18:04< Guest9655> OK. I'll add it to my list. Any ETA on tagging 1.13.5?
20160724 02:18:05< celmin> However, I'm not sure which of the two is the expected behaviour and which is the buggy behaviour.
20160724 02:18:32< celmin> I don't really know. Vultraz is in charge of that, as I recall.
20160724 02:19:06< Guest9655> I would suggest the different names is the correct behavior. Otherwise why have it in [side] at all .. you're better off, then, with a [team] tag describing the team-common information.
20160724 02:19:21< celmin> …that would be a great idea.
20160724 02:19:36< ancestral> celmin: Okay, built and working
20160724 02:19:46< celmin> But you're probably correct, I would guess.
20160724 02:19:56< ancestral> Will not run without sdl2_net 
20160724 02:20:29< celmin> Hmm.
20160724 02:20:43< ancestral> vultraz: I’m hopeful the issue with OS X building in 1.13 will be fixed with 1.13.5
20160724 02:21:40-!- Guest9655 [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160724 02:21:46< ancestral> The 1.12 build I have an idea that might let it run on older versions. I might need to table that until Tuesday/Wednesday
20160724 02:22:28< celmin> ancestral: If SDL_net is referenced only from that one file, then I would say just remove the references to it - that file's purpose seems to be showing version info to the user, and it's silly to do that for a library that's not actually being used in my opinion.
20160724 02:22:52< ancestral> I can try
20160724 02:23:07< ancestral> You sure it’s not used for wesnoth server?
20160724 02:23:09< celmin> …there might actually be no references to it...
20160724 02:23:20< celmin> Yeah, the Wesnoth server no longer depends on it. 
20160724 02:23:48< celmin> (But if you don't want to take my word on it, feel free to try hosting a local MP game yourself.)
20160724 02:23:48< ancestral> build_info.cpp:28
20160724 02:24:10< ancestral> So, I should comment that out???
20160724 02:24:34< ancestral> I feel like that should be a PR
20160724 02:24:40< celmin> Hmm?
20160724 02:24:45< celmin> Comment which out?
20160724 02:24:51< ancestral> #include <SDL_net.h> is in build_info.cpp
20160724 02:24:55< ancestral> Line 28
20160724 02:25:03< celmin> Oh, yeah, try deleting that.
20160724 02:25:10< ancestral> Well, that will probably work
20160724 02:25:11< celmin> I have a feeling nothing is actually used from it.
20160724 02:25:42< ancestral> I can try that if you want me to test it. I guess I’m just saying that’s not a good solution ;-)
20160724 02:26:06< celmin> I think it's a good solution, because the issue here is that someone missed one when removing SDL_net.
20160724 02:26:07< ancestral> Making a commit
20160724 02:26:37< ancestral> So you’d like me to test if it builds without that line, and if it does, you’d like to make a PR to delete it?
20160724 02:26:55< celmin> Uh, sure, you can make a PR if you want.
20160724 02:27:56< ancestral> Okay, it builds with that line commented out and the lib gone
20160724 02:27:59< ancestral> Cool
20160724 02:28:38< ancestral> Okay, so I’m going to double check that the libraries I have aren’t pointing to local paths
20160724 02:28:50< ancestral> If that works, then I’ll put up a new Mac Compile Stuff
20160724 02:36:31-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 1555 Yes, 310 No | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160724 02:36:43< vultraz> We're number 63
20160724 02:37:28< vultraz> the initial surge of votes has kinda tapered off
20160724 02:38:29< celmin> I should get my sister to vote, not that it'll make much difference.
20160724 02:39:48< vultraz> At this point it's basically a certainty that we get Greenlit
20160724 02:42:21< vultraz> celmin, ancestral: I thought I removed the ref to SDL_net from build_info
20160724 02:43:43< ancestral> I guess you missed one
20160724 02:43:44< ancestral> https://github.com/wesnoth/wesnoth/blob/master/src/build_info.cpp#L28
20160724 02:43:55< ancestral> the include statement
20160724 02:44:16-!- RatArmy [~RatArmy@om126229088089.12.openmobile.ne.jp] has joined #wesnoth-dev
20160724 02:44:17< vultraz> derp
20160724 02:44:21< vultraz> please do remove :P
20160724 02:44:36-!- RatArmy [~RatArmy@om126229088089.12.openmobile.ne.jp] has quit [Client Quit]
20160724 02:44:37< vultraz> no need to PR
20160724 02:44:40< ancestral> Permission to edit master?
20160724 02:44:42< ancestral> Okay
20160724 02:45:23-!- irker559 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160724 02:45:23< irker559> wesnoth: ancestral wesnoth:master ce50063f1a08 / src/build_info.cpp: Removed include for sdl_net https://github.com/wesnoth/wesnoth/commit/ce50063f1a08801e15a4a1a40a84973c971f77b1
20160724 02:47:30< ancestral> vultraz: Wondering if maybe the text can be adjusted slightly up on the buttons in the UI?
20160724 02:47:36< ancestral> By a pixel or two?
20160724 02:48:01< ancestral> They seem a bit low on the buttons
20160724 02:48:28< celmin> I wouldn't be surprised if that's because he reverted my centering change.
20160724 02:48:30< ancestral> http://uploadpie.com/lwCCM
20160724 02:48:35< celmin> …well, reverted isn't the right word.
20160724 02:48:45< vultraz> celmin: your centering change made it off-center
20160724 02:49:00< celmin> That's not true.
20160724 02:49:09< celmin> It was off-center before I did that, after all.
20160724 02:49:33< celmin> If I recall correctly.
20160724 02:50:39< celmin> https://github.com/wesnoth/wesnoth/commit/47bb358003efa3d19571ecd0970c1adfa3866d95
20160724 02:51:13< celmin> ancestral: I'm not sure whether reverting that is the way to fix it, but that's the general area where a fix would be applied, at least.
20160724 02:51:20< ancestral> Yeah
20160724 02:51:37 * celmin suspects reverting is not the answer - +2 would probably move it down even more, right?
20160724 02:51:49< irker559> wesnoth: Charles Dang wesnoth:master aea6cbbabc10 / data/gui/macros/_initial.cfg: Tiny tweak to vertically centered text to make it more centered https://github.com/wesnoth/wesnoth/commit/aea6cbbabc105a24274ae70385d65656a13315ad
20160724 02:51:54< vultraz> ancestral: ^ try that
20160724 02:51:57< ancestral> It’s been a while. Can’t remember if +Y is up or down
20160724 02:52:06< ancestral> vultraz: Cool
20160724 02:52:25< celmin> Should probably be subtracting 2 instead of 1 there, vultraz 
20160724 02:52:35< vultraz> no, 2 is too much
20160724 02:52:36< celmin> What you just did shifts it by half a pixel.
20160724 02:52:38< ancestral> Looks good to me
20160724 02:52:50< celmin> ...
20160724 02:53:03< vultraz> well, I could have subbed the one after the division
20160724 02:53:03< celmin> But it's only half a pixel.
20160724 02:53:13< celmin> That's why I said 2, because of the division.
20160724 02:53:25< celmin> You could have.
20160724 02:53:39< vultraz> It works, so don't question :P
20160724 02:53:52< ancestral> http://uploadpie.com/FL7Pj
20160724 02:53:55< celmin> I make no promises.
20160724 02:54:16< vultraz> yeah, that looks pretty much exactly what we want
20160724 02:55:01< vultraz> that's for bringing that up
20160724 02:59:10< vultraz> ancestral: so your build works?
20160724 02:59:32< ancestral> Yes
20160724 02:59:59< ancestral> So I can make 1.13.5 when you want to release
20160724 03:00:23< celmin> You don't need to do anything about the Boost placeholders?
20160724 03:00:29< ancestral> Yes, okay
20160724 03:00:38< ancestral> So there’s a bug with BOOST_STATIC_ASSERT
20160724 03:00:51< celmin> Wait, it's actually a bug with BOOST_STATIC_ASSERT?
20160724 03:00:52< ancestral> And I can’t figure out how to get around it without commenting it out
20160724 03:01:03< vultraz> ancestral: does that mean https://gna.org/bugs/index.php?24541 is also fixed
20160724 03:01:04< ancestral> Let me uncomment it and quote the error
20160724 03:01:32< celmin> Does it work if you #define BOOST_STATIC_ASSERT(cond) static_assert(cond, #cond)
20160724 03:01:33< celmin> ?
20160724 03:01:38< vultraz> ancestral: and could you please confirm which of the macOS bugs listed in the RELEASE_NOTES are fixed and can be removed?
20160724 03:01:40< ancestral> vultraz: I need to look into the library files and see where they are pointing to
20160724 03:01:44< ancestral> Then I can confirm it’s fixed
20160724 03:01:56< celmin> …though honestly I'd expect it to be defined that way anyway if you're building as C++11.
20160724 03:01:57< ancestral> I will do that likely tomorrow
20160724 03:02:07< ancestral> Or maybe late tonight
20160724 03:02:23< ancestral> celmin: Let’s see
20160724 03:03:28< ancestral> Maybe it got fixed by addressing a different error I got
20160724 03:04:06< celmin> You added references to std::placeholders:: right? That would bypass the problem if it was just in arg.hpp
20160724 03:04:30-!- JyrkiVesterinen [~JyrkiVest@87-100-147-187.bb.dnainternet.fi] has joined #wesnoth-dev
20160724 03:04:34< celmin> You might need to remove one of those to see if it's actually fixed.
20160724 03:04:37< ancestral> Nope, issue remains
20160724 03:04:43< celmin> Right...
20160724 03:04:44< ancestral> And I did
20160724 03:04:50< ancestral> the std::placeholders::
20160724 03:04:59< ancestral> Oh
20160724 03:05:02< celmin> I want to avoid adding the std::placeholders
20160724 03:05:05< ancestral>  /Users/xxxx/Documents/Pilot/wesnoth 1.13/projectfiles/Xcode/Headers/boost/bind/arg.hpp:37:9: Static_assert failed "I == is_placeholder<T>::value"
20160724 03:05:38< celmin> If possible
20160724 03:05:53< celmin> So is it actually a bug with BOOST_STATIC_ASSERT?
20160724 03:06:23< vultraz> optimally we should refactor our code to get rid of the uses of boost::...something
20160724 03:06:32< vultraz> bind
20160724 03:06:46< celmin> Pretty sure we already did that.
20160724 03:06:51< celmin> That was the cause of this mess, in fact.
20160724 03:07:19< ancestral> arg.hpp:37
20160724 03:07:26< vultraz> nope, it's still in 29 places
20160724 03:07:48< celmin> Oh right, Boost.Bind has different semantics than std::bind, so that's why.
20160724 03:08:02< ancestral> Okay question
20160724 03:08:06< ancestral> What is a header map?
20160724 03:08:15< celmin> Still, replacing boost::bind with std::bind is basically what caused this mess, pretty sure.
20160724 03:08:17< celmin> A what now?
20160724 03:08:35< ancestral> Build Settings > Search Paths > Use Header Maps
20160724 03:08:55< ancestral> If I set that to no, the error goes away… I think
20160724 03:09:05< ancestral> Building…
20160724 03:09:19< celmin> I have no clue what that is.
20160724 03:09:24< ancestral> Nope, never mind; just extremely wishful thinking
20160724 03:09:39< ancestral> (When I clicked on the error icon it brought me to that line in the build settings in Xcode)
20160724 03:09:43< celmin> By the way, you didn't do something like "upgrade project to recommended blah blah" did you.
20160724 03:10:02< celmin> Weird.
20160724 03:10:42< ancestral> I didn't
20160724 03:10:45< ancestral> Tempted, did not
20160724 03:10:53< ancestral> I tried that before and things would barf
20160724 03:11:04< ancestral> Violent Xcode vomitting
20160724 03:11:10< celmin> Doing that would likely break everything for me as well.
20160724 03:12:27< ancestral> celmin: The BOOST_STATIC_ASSERT
20160724 03:12:34< ancestral> Technically errors 4 times
20160724 03:12:36< ancestral> Same line
20160724 03:12:45< ancestral> So there must be four assertions or something
20160724 03:12:52< ancestral> Four instances?
20160724 03:13:23< celmin> Well, it's the copy constructor for boost::arg
20160724 03:13:39< celmin> Which probably means it occurs in cases where a bound functor using a placeholder needs to be copied? Or something like that.
20160724 03:14:12< ancestral> http://stackoverflow.com/questions/8631769/how-to-use-boost-static-assert
20160724 03:14:34< ancestral> “C++11 and C11 add the static_assert language construct, so you won't need Boost any more.”
20160724 03:14:45< celmin> Keep in mind that this arg.hpp is part of Boost.
20160724 03:14:46< ancestral> “It does not work for ordinary function arguments.”
20160724 03:14:51< ancestral> Right
20160724 03:15:24< celmin> I would have expected BOOST_STATIC_ASSERT to be defined as a synonym to the built-in static_assert.
20160724 03:15:27< celmin> …wait.
20160724 03:15:29< vultraz> are we supposed to use an standard lib thing here?
20160724 03:15:34< vultraz> s/an/a
20160724 03:15:48< celmin> Looking at the error message again, it probably is defined that way.
20160724 03:16:12< celmin> Does the error message say anywhere what T is?
20160724 03:16:21< celmin> Either on that line or in one of the grey supplementary lines.
20160724 03:16:33< ancestral> one sec
20160724 03:17:07< ancestral> https://paste.ee/p/Gh27k
20160724 03:17:24< ancestral> That’s the whole function
20160724 03:17:30< ancestral> er, template
20160724 03:17:54< celmin> That wasn't what I was asking for...
20160724 03:18:47< celmin> …waaait a second, isn't it impossible for I == std::is_placeholder<T>::value to be true? Except maybe with I == 1
20160724 03:19:31< celmin> I'm pretty sure std::is_placeholder<T>::value is a bool for any T.
20160724 03:19:43< celmin> Or, wait, maybe I should look this up.
20160724 03:20:20< celmin> Okay, I was wrong.
20160724 03:20:33< celmin> So anyway, what's T?
20160724 03:21:01< celmin> Somewhere in the error message is likely a "[with T = …]" note.
20160724 03:21:25< ancestral>  /Users/martinproud/Documents/Pilot/wesnoth 1.13/projectfiles/Xcode/Headers/boost/bind/arg.hpp:37:9: Static_assert failed "I == is_placeholder<T>::value"
20160724 03:21:29< ancestral> That’s what I got
20160724 03:21:58< celmin> One of the grey lines probably.
20160724 03:22:13< celmin> Hidden under the disclosure triangle by default.
20160724 03:24:55-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160724 03:26:10< ancestral> Oh
20160724 03:26:11< ancestral> Sorry
20160724 03:27:03< ancestral> celmin: https://paste.ee/p/H83wl
20160724 03:28:37< celmin> Eh? Why is it trying to construct an arg from a tuple?
20160724 03:29:37< celmin> Wait, this is all through an is_convertible call? Isn't that a violation of SFINAE?
20160724 03:29:49< ancestral> Okay I have 3 more, slightly different
20160724 03:31:03< celmin> Maybe static_assert doesn't count as substitution failure...
20160724 03:31:27< ancestral> #2 https://paste.ee/p/xWN1k
20160724 03:31:28< ancestral> #3 https://paste.ee/p/9zPjP
20160724 03:31:28< ancestral> #4 https://paste.ee/p/1Z05P
20160724 03:34:34< celmin> ancestral: What C++ standard is it using? C++11 or C++14?
20160724 03:34:54< ancestral> What is it?
20160724 03:35:08< celmin> In Build Settings
20160724 03:35:44< ancestral> Default compiler Apple LLVM 7.1…
20160724 03:35:57< celmin> Should be a couple lines below that
20160724 03:36:20< celmin> Language standard
20160724 03:36:36< ancestral> C++11[-std=c++11]
20160724 03:36:48< vultraz> ok that's what we do
20160724 03:36:51< vultraz> use*
20160724 03:36:53< celmin> Well, that's good at least.
20160724 03:37:00< ancestral> libc++ (LLVM C++ standard library with C++11 support)
20160724 03:37:27< celmin> I'm tempted to hack out BOOST_STATIC_ASSERT specifically when including Boost.Bind.
20160724 03:37:27< ancestral> There is a libstdc++ (GNU C++ standard library) available
20160724 03:37:37< ancestral> Also
20160724 03:37:39< celmin> By undeffing it and redeffing it to an empty string.
20160724 03:37:45< ancestral> Enable C++ Exceptions: Yes
20160724 03:37:52< ancestral> Enable C++ Runtime Types: Yes
20160724 03:37:52< celmin> Yeah, that's all fine.
20160724 03:37:57< celmin> No problem.
20160724 03:38:07< celmin> Not relevant to this issue.
20160724 03:38:26< celmin> I'm surprised libstdc++ is still offered though.
20160724 03:39:09< JyrkiVesterinen> celmin: Apple is likely offering libstdc++ for the purpose of projects which are too afraid to switch to libc++.
20160724 03:39:16< celmin> I see...?
20160724 03:39:48< ancestral> I do have some custom compiler flags, but probably the same ones you have, celmin
20160724 03:39:56< celmin> Probably
20160724 03:41:12< JyrkiVesterinen> One such project is an extremely well-known mobile game I have worked on. We (programmers in the development team) were quite frustated that the version of libstdc++ offered by Apple is ancient and significantly reduced the C++11 library features we were able to use.
20160724 03:41:27< ancestral> So one of the errors is stemming from src/scripting/application/lua_kernel.cpp:288
20160724 03:41:38< JyrkiVesterinen> A later version of our in-house game engine supported libc++ (and only libc++, it dropped libstdc++ support).
20160724 03:42:10< celmin> Last I checked, Apple's version of libstdc++ didn't support C++11 at all...
20160724 03:42:28< JyrkiVesterinen> However, the new version of the engine is significantly different. No one wanted to spend the effort to upgrade the engine in the project.
20160724 03:42:36-!- ggeneral [~ggeneral@37.73.210.71] has joined #wesnoth-dev
20160724 03:42:43< JyrkiVesterinen> I believe they're still using the old version, and thus libstdc++.
20160724 03:43:08< celmin> Huh.
20160724 03:43:40< JyrkiVesterinen> celmin: Even libstdc++ 4.2.x has some preliminary C++11 support. I used the C++11 features which were available.
20160724 03:44:09< celmin> I don't suppose you have any insight into ancestral's bind issue.
20160724 03:44:10< JyrkiVesterinen> In general, anything that worked on libstdc++ 4.2 worked on all other supported platforms as well.
20160724 03:44:24< JyrkiVesterinen> Indeed, I don't have any insight about that.
20160724 03:45:24< ancestral> celmin: I keep seeing lua_kernel involved
20160724 03:45:38< celmin> ancestral: I don't believe that's actually relevant to the underlying problem.
20160724 03:45:44< ancestral> Okay
20160724 03:46:02< celmin> Oh, by the way...
20160724 03:46:03< ancestral> #2 has a __1
20160724 03:46:22< celmin> If you find the actual bind line in whichever file, is it std::bind or boost::bind?
20160724 03:47:18-!- ggeneral [~ggeneral@37.73.210.71] has quit [Ping timeout: 276 seconds]
20160724 03:47:44< celmin> I suppose it miiight be useful to look at the bind lines and see if they have anything in common that could point to the issue.
20160724 03:48:12< ancestral> Looking
20160724 03:48:56< ancestral> http://www.boost.org/libs/bind/bind.html
20160724 03:49:08< ancestral> Looking
20160724 03:49:35< celmin> Why'd you link Boost.Bind docs?
20160724 03:50:15< ancestral> Wasn’t sure if it would tell me anything
20160724 03:50:28< ancestral> So
20160724 03:50:36< ancestral> All I see are header files
20160724 03:50:43< ancestral> Which aren’t going to instantiate bind
20160724 03:50:47< ancestral> Right?
20160724 03:50:49< celmin> Huh?
20160724 03:51:05< ancestral> I need to look in the Wesnoth files?
20160724 03:51:12-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 276 seconds]
20160724 03:51:18< celmin> It should be in the error messages?
20160724 03:51:31< celmin> The places you added std::placeholders
20160724 03:51:38< ancestral> “#include <boost/bind.hpp> // Because std::bind is just not flexible enough”
20160724 03:51:59< ancestral> src/utils/functional.hpp:23
20160724 03:52:04< celmin> Maybe you can even find them with git diff or something if you haven't reverted them all.
20160724 03:52:14< ancestral> You want me to change them all?
20160724 03:52:24< celmin> No?
20160724 03:52:31< ancestral> Okay
20160724 03:52:34< celmin> I would like to see the ones that caused problems.
20160724 03:52:45< celmin> There were only a few, I thought?
20160724 03:53:15< ancestral> Okay I see lots of std::bind
20160724 03:53:25< ancestral> ai.cpp
20160724 03:53:37< ancestral> application_lua_kernel.cpp
20160724 03:53:43< ancestral> ban.cpp
20160724 03:53:48< ancestral> etc.
20160724 03:53:56< celmin> Are these all the places you needed to add std::placeholders to get it to compile?
20160724 03:54:10< ancestral> I see some boost::bind too
20160724 03:54:24< ancestral> Hmm
20160724 03:54:46< ancestral> Ahhh
20160724 03:55:04< ancestral> Okay, ai.cpp has _1,_2
20160724 03:55:09< ancestral> But it didn’t error
20160724 03:56:01< ancestral> application_lua_kernel also has _1 and _2
20160724 03:56:07< ancestral> Okay
20160724 03:56:21< ancestral> so std::bind is using _1 syntax
20160724 03:56:44< ancestral> so is boost::bind
20160724 03:56:47< celmin> Yes.
20160724 03:56:54< celmin> _1 is an instance of boost::arg
20160724 03:57:16< celmin> In functional.hpp (I think it was called) is a little code that enables it to also work with std::bind
20160724 03:58:02< ancestral> Okay, so ai.cpp, ban.cpp, functional.hpp, manager.cpp, play_controller.cpp and wesnoth.cpp all have  std::placeholders::_1 syntax
20160724 03:58:14< celmin> I thought you just said they don't.
20160724 03:58:30< celmin> At least the first two
20160724 03:58:45< celmin> There's some with and some without in that file?
20160724 03:58:54< ancestral> Different lines in the same file apparently use both syntaxes
20160724 03:58:56< ancestral> Yes
20160724 03:59:13< ancestral> Okay so ai.cpp
20160724 03:59:19< celmin> And the ones that use it were just changed by you?
20160724 03:59:40< ancestral> Line 79 has _1, and Line 82 has std::placeholders::_1 changed by me
20160724 04:00:00< celmin> Could you perhaps make a paste containing all the lines that do have std::placeholders?
20160724 04:00:11< vultraz> huh
20160724 04:00:15< celmin> (Or maybe more than a line, if the function call is spread over several lines.)
20160724 04:00:24< vultraz> server/server.cpp is a major user of boost::bind
20160724 04:01:00< ancestral> celmin: 9 of them: https://paste.ee/p/INgFq
20160724 04:02:49< celmin> Hmm, not sure I can see anything in common amongst them… though several of them appear to be binding member functions...
20160724 04:03:20< celmin> But I can't tell if all of them are, and even if they all are that wouldn't mean anything unless they're actually the only ones that are, I think.
20160724 04:03:42< vultraz> celmin: I'm testing changing a few of the remaining cases of boost::bind to std::bind and they seem to build for me...
20160724 04:03:54< vultraz> celmin: are all the cases ones that would not build for you?
20160724 04:04:18< celmin> JyrkiVesterinen: You were using MSVC12, right?
20160724 04:04:28< celmin> vultraz: I don't remember.
20160724 04:04:49< celmin> But you also need to verify that they build for zookeeper, ie MSVC12
20160724 04:04:59< JyrkiVesterinen> celmin: Are you talking about Wesnoth development? If so, yes, I use MSVC12 to develop Wesnoth.
20160724 04:05:31< ancestral> Never hurts to have another person building master :)
20160724 04:05:34< celmin> vultraz: So what are these boost::bind cases?
20160724 04:05:44< vultraz> celmin: let me get you a diff
20160724 04:07:23-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160724 04:08:15< vultraz> celticminstrel: http://pastebin.com/g7gESNXd
20160724 04:08:34< vultraz> that's all the remaining cases of plain boost::bind. bind_void, however, is still used 
20160724 04:09:09< vultraz> I'm pretty sure the tod_manager section could be refactored 
20160724 04:09:11< celticminstrel> I don't remember what bind_void was.
20160724 04:09:27< vultraz> 2. A function that returns a value cannot be bound in a function type that returns void.
20160724 04:09:28< vultraz> This is also relied upon in several places.
20160724 04:09:30< vultraz> If behaviour #1 is needed, we need to use boost::bind. For behaviour #2, this won't work;
20160724 04:09:31< vultraz> instead, the bind_void function is provided. 
20160724 04:09:31< celticminstrel> Oh right, one that ignores the return value.
20160724 04:10:11< celticminstrel> Behaviour #1 is ignoring excess arguments?
20160724 04:11:29< celticminstrel> JyrkiVesterinen: Do you think you could test if the patch in vultraz's paste works?
20160724 04:12:05< JyrkiVesterinen> OK, I'll test it. (Will take a while, I need to do an almost-clean rebuild because I have last built an old revision.)
20160724 04:12:16< celticminstrel> Me too.
20160724 04:12:32-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160724 04:12:32< celticminstrel> I was several commits behind, so it'll take be some time to test it.
20160724 04:12:44< celticminstrel> ^me
20160724 04:14:12-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20160724 04:14:57< celticminstrel> Though only five source files changed, so maybe not that long...
20160724 04:15:05< celticminstrel> I shall see.
20160724 04:15:32-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160724 04:16:09< JyrkiVesterinen> "fatal: corrupt patch at line 45"
20160724 04:16:11< vultraz> celticminstrel: could you see if the diff builds for you?
20160724 04:16:20< JyrkiVesterinen> I guess I'll just make the changes manually, it's not much...
20160724 04:16:31< vultraz> it's only cpp files so it shouldn't take long
20160724 04:16:51< celticminstrel> I plan to.
20160724 04:17:13< vultraz> if it builds I'll commit these
20160724 04:17:23< vultraz> (note I cannot use std::copy in the tod_manager block)
20160724 04:17:27< celticminstrel> If it builds for both me and JyrkiVesterinen.
20160724 04:18:05< vultraz> wish I could understand what that code even does
20160724 04:18:13< celticminstrel> Obviously - boost::copy is completely different from std::copy.
20160724 04:18:19< celticminstrel> I thought that code was pretty clear.
20160724 04:18:54< vultraz> Do explain it, then
20160724 04:19:26< celticminstrel> First, split random_tod_.str() to produce a vector<string>
20160724 04:19:56< celticminstrel> Pass that through std::transform(begin(), end(), begin(), lexical_cast_default<int, string>)
20160724 04:20:12< celticminstrel> (Something like that, don't recall std::transform's exact API from the top of my head.)
20160724 04:20:50< celticminstrel> Remove all elements for which greater<int>(0) returns false, ie all negative or zero values.
20160724 04:21:03< celticminstrel> Finally, copy the result over to the output vector.
20160724 04:21:53< celticminstrel> In other words, for every element of the split, it converts it to an integer and discards it if non-positive or puts it in output if positive.
20160724 04:21:59< vultraz> couldn't that be simplified somewhat
20160724 04:22:05< celticminstrel> Not really.
20160724 04:22:26< celticminstrel> I mean, it could be rewritten to not use boost::copy, but I think that would be the opposite of simplifying.
20160724 04:23:02< celticminstrel> It might help to think of | here as the pipe operator, just like in the command prompt.
20160724 04:23:09< JyrkiVesterinen> Build succeeded with vultraz's patch.
20160724 04:23:13< celticminstrel> ...if you're familiar with that, which you might not be on Windows.
20160724 04:23:28< celticminstrel> Okay, good, now just waiting for my result...
20160724 04:23:35< vultraz> I am familiar with pipes
20160724 04:23:50< celticminstrel> Fair enough.
20160724 04:24:20< celticminstrel> So, you can think of it as taking the output of utils::split, piping it through the transform and the filter, and inserting the result into output.
20160724 04:24:50< vultraz> that makes a lot more sense
20160724 04:26:03< JyrkiVesterinen> Oh, wait. Actually the build failed, I misread the output.
20160724 04:26:12< celticminstrel> Oh.
20160724 04:26:14-!- Appleman1234 [~Appleman1@KD036012034186.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20160724 04:26:14< JyrkiVesterinen> The error message is long, I'll upload it to Gist.
20160724 04:27:04< JyrkiVesterinen> https://gist.github.com/jyrkive/fcc4c336b3e85e27d73b61d683a937c2
20160724 04:29:20< vultraz> out to lunch, be back later
20160724 04:29:26< celticminstrel> Huh...
20160724 04:29:31< ancestral> tod_manager.cpp
20160724 04:30:46< celticminstrel> Well, that does look like it's just cause by the change in tod_manager.cpp, so maybe see if it works if you revert just that one?
20160724 04:31:13< vultraz> the change in the gui2 file is being an idef, so it shouldnt affect anything
20160724 04:32:38-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160724 04:34:24< JyrkiVesterinen> I reverted the change in tod_manager.cpp, and the build seems to be getting further. Still building...
20160724 04:35:36< JyrkiVesterinen> If tod_manager::resolve_random() ends up as the only place where boost::bind() is used, we may want to rewrite it to use standard library algorithms instead of Boost's pseudo-pipes.
20160724 04:36:17< celticminstrel> Maybe.
20160724 04:40:06< Aginor> it would make sense, no point in doing things in two different ways if we can avoid it
20160724 04:40:26< celticminstrel> bind_void might also be implemented with boost::bind... though maybe that can be changed...
20160724 04:41:11< celticminstrel> Does anyone remember what Boost headers were implicitly including bind?
20160724 04:42:44< JyrkiVesterinen> Build failed again.
20160724 04:42:44< celticminstrel> Aww...
20160724 04:42:44< JyrkiVesterinen> 1>i:\battle for wesnoth\wesnoth\src\hotkey\command_executor.cpp(61): error C3848: expression having type 'const std::_Bind<true,bool,std::_Pmf_wrap<bool (__thiscall display::* )(const std::string &,bool),bool,display,const std::string &,bool>,display *,const boost::arg<1> &,bool>' would lose some const-volatile qualifiers in order to call 'bool std::_Bind<true,bool,std::_Pmf_wrap<bool (__thiscall display::* )(const std::
20160724 04:42:44< JyrkiVesterinen> string &,bool),bool,display,const std::string &,bool>,display *,const boost::arg<1> &,bool>::operator ()<std::string&,CVideo&>(std::string &,CVideo &)'
20160724 04:42:44< JyrkiVesterinen> 1>          i:\battle for wesnoth\wesnoth\src\hotkey\command_executor.cpp(738) : see reference to function template instantiation 'void `anonymous-namespace'::make_screenshot<std::_Bind<true,bool,std::_Pmf_wrap<bool (__thiscall display::* )(const std::string &,bool),bool,display,const std::string &,bool>,display *,const boost::arg<1> &,bool>>(const std::string &,CVideo &,const TFunc &)' being compiled
20160724 04:42:44< JyrkiVesterinen> 1>          with
20160724 04:42:44< JyrkiVesterinen> 1>          [
20160724 04:42:44< JyrkiVesterinen> 1>              TFunc=std::_Bind<true,bool,std::_Pmf_wrap<bool (__thiscall display::* )(const std::string &,bool),bool,display,const std::string &,bool>,display *,const boost::arg<1> &,bool>
20160724 04:42:44< JyrkiVesterinen> 1>          ]
20160724 04:44:52< celticminstrel> Hmm, not sure I get it, but maybe I'll get the same error.
20160724 04:47:40-!- Appleman1234 [~Appleman1@KD036012047012.au-net.ne.jp] has joined #wesnoth-dev
20160724 04:48:03< JyrkiVesterinen> Hmm, make_screenshot is passing two parameters to the function.
20160724 04:48:04< JyrkiVesterinen> const bool res = func(filename, video);
20160724 04:48:18< JyrkiVesterinen> Meanwhile, the bound function only accepts one.
20160724 04:48:40< JyrkiVesterinen> make_screenshot(_("Map-Screenshot"), get_video(), std::bind(&display::screenshot, &get_display(), _1, true));
20160724 04:48:59< JyrkiVesterinen> (Only the _1 placeholder is used. In other words, only one parameter.)
20160724 04:49:08< celticminstrel> For the record, if replacing all instances of bind_void with bind_void_exact still compiles, then bind_void_exact can be removed and no more reliance on Boost.Bind would be needed.
20160724 04:49:24< JyrkiVesterinen> Rewriting make_screenshot to use std::function might help...
20160724 04:49:39< celticminstrel> Hmmm.
20160724 04:50:56< JyrkiVesterinen> Oh, utils/functional.hpp has an useful note.
20160724 04:50:58< JyrkiVesterinen> 1. The functions produced do not silently consume extra parameters passed to them.
20160724 04:50:58< JyrkiVesterinen> This is not a bad thing per se, but some of Wesnoth's code relied on it.
20160724 04:50:58< JyrkiVesterinen> It's useful behaviour, as well.
20160724 04:51:14< JyrkiVesterinen> (The above three lines were quoted from it.)
20160724 04:51:15< celticminstrel> This is a good question. Why is it passing a true parameter which would never be used anyway? Some relic of something?
20160724 04:51:52< JyrkiVesterinen> That note in functional.hpp explains why make_screenshot works with boost::bind but not with std::bind.
20160724 04:51:59< celticminstrel> Yeah, I wrote that note.
20160724 04:52:58< celticminstrel> Though a couple of hours ago I saw a StackOverflow answer that implied std::bind should also discard the excess arguments... I dunno...3
20160724 04:53:14< celticminstrel> Okay, so display::screenshot does take two arguments...
20160724 04:53:24< celticminstrel> Oh wait, the other end.
20160724 04:54:10< celticminstrel> I think a different function passed to make_screenshot needed the second argument...
20160724 04:55:50< JyrkiVesterinen> I replaced the bind with a lambda. Testing if that will build.
20160724 04:56:44< celticminstrel> I was testing removing the need for the video argument by binding ::screenshot at line 602, but it's not working.
20160724 04:57:15< celticminstrel> Oh.
20160724 04:57:28< celticminstrel> Forgot the placeholder.
20160724 04:58:01< celticminstrel> Eh? Now I've gotten ancestral's error?
20160724 04:59:59< celticminstrel> Does yours work, JyrkiVesterinen?
20160724 05:00:13< JyrkiVesterinen> I think so. It's still building.
20160724 05:00:39< celticminstrel> Incidentally, ancestral, the static_assert went away when I added an std::ref wrapper around an argument...
20160724 05:01:11< JyrkiVesterinen> Build succeeded with the lambda. :)
20160724 05:01:11< celticminstrel> Not sure if that would help in your case, but if there are arguments that look like they should be passed by reference, it could be worth a try.
20160724 05:03:12< celticminstrel> Something like [this](const std::string& fname, CVideo&) {get_display().screenshot(fname, true);} ?
20160724 05:04:12 * celticminstrel adds "return" to that to get it to work.
20160724 05:04:51-!- TC02 [~quassel@venus.arosser.com] has quit [Ping timeout: 240 seconds]
20160724 05:05:06-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20160724 05:05:51< celticminstrel> Hmm, bind_void is used in seven places...
20160724 05:06:50< JyrkiVesterinen> Here's a patch of my changes. The game compiles with them for me.
20160724 05:06:51< JyrkiVesterinen> https://gist.github.com/jyrkive/13ffb7c4bb2b7105c9eedd514bf5b4fc
20160724 05:10:35-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160724 05:16:07< celticminstrel> BTW vultraz: regarding server/server.cpp, maybe we merged that branch in after changing all the other boost::binds to std::bind?
20160724 05:17:10< celticminstrel> Incidentally, I'm not getting any errors from changing bind_void to std::bind, though it's still building so there might yet be some.
20160724 05:17:27< celticminstrel> (In the implementation, I mean - so it uses std::bind instead of boost::bind)
20160724 05:19:06-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160724 05:20:11-!- TC02 [~quassel@venus.arosser.com] has quit [Ping timeout: 240 seconds]
20160724 05:21:24< celticminstrel> Well, it works for me. I suppose it would be good for JyrkiVesterinen to verify too.
20160724 05:21:49< celticminstrel> (Lines 96 and 102 of functional.hpp -> std::bind)
20160724 05:22:23-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20160724 05:22:49-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160724 05:23:08< JyrkiVesterinen> I changed it and started a rebuild.
20160724 05:23:32< celticminstrel> If that works, I'll commit this and the patch you posted.
20160724 05:25:05-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160724 05:28:47-!- Kwandulin [~Miranda@p200300760F60624D8CF14E5C2ED79A73.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160724 05:34:34-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160724 05:39:11< JyrkiVesterinen> celticminstrel: Build succeeded with bind_void changed to use std::bind.
20160724 05:39:23< celticminstrel> 'kay
20160724 05:41:43< vultraz> celticminstrel: I'll let you commit these changes
20160724 05:42:15-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 1629 Yes, 331 No | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160724 05:42:36< celticminstrel> Still the 7th day of th 24th month though, huh.
20160724 05:42:41< celticminstrel> ^the
20160724 05:43:35 * celticminstrel curls your patch straight into git am. >_>
20160724 05:46:54< vultraz> so wait, we don't need bind_void now?
20160724 05:46:56< vultraz> what changed
20160724 05:47:11< celticminstrel> You misunderstand.
20160724 05:47:22< celticminstrel> We still have bind_void, but now it doesn't use boost::bind.
20160724 05:47:27< vultraz> Oh, I see
20160724 05:47:36< vultraz> So do we need boost_bind at all?
20160724 05:47:40< vultraz> boost::bind*
20160724 05:47:51< celticminstrel> Ideally, no.
20160724 05:48:07< vultraz> (besides in server.cpp which should be safe to change)
20160724 05:48:21< celticminstrel> There's still server.cpp and tod_manager.cpp.
20160724 05:48:33< vultraz> oh, the tod_manager doesn't work?
20160724 05:48:36< vultraz> change*
20160724 05:48:40< celticminstrel> Yeah.
20160724 05:48:50< vultraz> ok, we'll have to figure that out..
20160724 05:49:18< celticminstrel> We could do what JyrkiVesterinen suggested and switch to standard library algorithms along with a temporary string vector.
20160724 05:49:31< celticminstrel> It's probably less efficient.
20160724 05:49:34< vultraz> It'd be nice to use std::bind everywhere and then remove the placeholders hack
20160724 05:49:58< celticminstrel> We can't remove the placeholders hack.
20160724 05:50:13< celticminstrel> The reason we have the placeholders hack is that some Boost headers include Boost.Bind implicitly.
20160724 05:51:33< vultraz> We're still including a lot of boost headers because we haven't converted their usecases to std:: yet, though
20160724 05:51:37< vultraz> like with shared_ptr
20160724 05:52:00-!- irker559 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160724 05:52:04< celticminstrel> I doubt that's one of the ones that was including bind though.
20160724 05:52:15< vultraz> we'll have to find out
20160724 05:53:05< vultraz> (is it shared_ptr or scoped_ptr?)
20160724 05:53:13< vultraz> or both?
20160724 05:53:32< celticminstrel> shared_ptr and unique_ptr
20160724 05:53:46< celticminstrel> Though according to StackOverflow, scoped_ptr can also be replaced with const unique_ptr
20160724 05:53:53< celticminstrel> Not sure if I want to do something like that though
20160724 05:55:34< vultraz> why are we still including boost/lexical_cast.hpp...?
20160724 05:56:05< celticminstrel> I dunno. Maybe it's still used somewhere? It's not like it's replaced by anything in the standard library.
20160724 05:56:26< vultraz> I shall see
20160724 05:56:54< celticminstrel> lexical_cast is very general. There's nothing in the C++ library that can replace it in all cases.
20160724 05:57:46< vultraz> yeah
20160724 05:58:02< vultraz> but we ship our own implementation
20160724 05:59:01< vultraz> ok, we still have 13 cases of boost::lexical_cast
20160724 05:59:09< vultraz> 8 of which are in tools/
20160724 05:59:17< vultraz> that leaves 5 in the regular source
20160724 06:01:35< celticminstrel> Well, lexical_cast is admittedly not all that hard to implement yourself; it's literally "put this in a string, stream it".
20160724 06:01:51< vultraz> celticminstrel: builds fine using our lexical_cast
20160724 06:02:18< celticminstrel> Just, don't commit something like this with 1.13.5 looming.
20160724 06:02:27< vultraz> celticminstrel: why don't we put this stuff in a PR
20160724 06:02:41< celticminstrel> I was going to push my stuff to a branch on master.
20160724 06:02:55< vultraz> you mean in the main repo?
20160724 06:02:56< celticminstrel> I was planning to call it bind_cleanup, but if you have a more general name...?
20160724 06:03:03< vultraz> boost_cleanup
20160724 06:03:05< celticminstrel> Yeah, that. Not master, of course.
20160724 06:03:16< celticminstrel> Maybe boost_trimming or something?
20160724 06:03:48< vultraz> trimming?
20160724 06:04:32< vultraz> just call it boost_*something*
20160724 06:04:43< vultraz> we can put all this boost cleanup in there
20160724 06:04:55< vultraz> merge it after 1.13.5
20160724 06:05:50-!- irker605 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160724 06:05:50< irker605> wesnoth: Celtic Minstrel wesnoth:boost_trimming 083ce3a52aef / src/utils/functional.hpp: Remove bind_void_exact, use std::bind for bind_void https://github.com/wesnoth/wesnoth/commit/083ce3a52aef7cb697d800851636f5ecc92e1ac1
20160724 06:05:50< irker605> wesnoth: Jyrki Vesterinen wesnoth:boost_trimming 3d140f988af6 / src/ (gui/dialogs/multiplayer/mp_create_game.cpp hotkey/command_executor.cpp): Remove two uses of boost::bind() https://github.com/wesnoth/wesnoth/commit/3d140f988af6afce1b879f21e8377bdf5f9b87b2
20160724 06:08:07< celticminstrel> Well, there you go. I was going to look at server.cpp and tod_manager.cpp (not in that order), but first, sleep.
20160724 06:08:48< celticminstrel> Feel free to push the lexical_cast thing or whatever.
20160724 06:09:06-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160724 06:10:44< JyrkiVesterinen> I'll make the tod_manager.cpp change myself and send a PR.
20160724 06:11:51< vultraz> can you change what branch the PR merges into?
20160724 06:12:59< JyrkiVesterinen> Yes, the GitHub UI allows me to make a PR for any branch.
20160724 06:13:16< vultraz> sweet, can you PR it against boost_trimmings?
20160724 06:15:04< JyrkiVesterinen> I already planned to do so.
20160724 06:16:34< vultraz> :)
20160724 06:22:00-!- Appleman1234 [~Appleman1@KD036012047012.au-net.ne.jp] has quit [Ping timeout: 276 seconds]
20160724 06:29:09< irker605> wesnoth: Charles Dang wesnoth:boost_trimming 211ba2e77024 / src/ (13 files in 6 dirs): Converted remaining cases of boost::lexical_cast to our own lexical_cast impleme https://github.com/wesnoth/wesnoth/commit/211ba2e77024ec33e30aef86d5235470de6e1de7
20160724 06:34:01< vultraz> now to convert shared_ptr and weak_ptr
20160724 06:34:51-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160724 06:40:41< vultraz> wonder if instead of using make_shared we should be using boost::intrusive_ptr
20160724 06:42:16-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has joined #wesnoth-dev
20160724 06:42:17< travis-ci> wesnoth/wesnoth#9918 (boost_trimming - 3d140f9 : Jyrki Vesterinen): The build passed.
20160724 06:42:17< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/146951264
20160724 06:42:17-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has left #wesnoth-dev []
20160724 06:52:17-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20160724 06:58:01-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160724 07:06:12-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 276 seconds]
20160724 07:07:52-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160724 07:09:04-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has joined #wesnoth-dev
20160724 07:09:05< travis-ci> wesnoth/wesnoth#9919 (boost_trimming - 211ba2e : Charles Dang): The build passed.
20160724 07:09:06< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/146952637
20160724 07:09:06-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has left #wesnoth-dev []
20160724 07:10:50< JyrkiVesterinen> vultraz: https://github.com/wesnoth/wesnoth/pull/711
20160724 07:11:42< vultraz> looks good to me
20160724 07:13:06< vultraz> JyrkiVesterinen: question, since you seem to be knowledgeable in this stuff: in the GUI2 code, there's a lot of uses of boost::intrusive_ptr mixed with boost::dynamic_pointer_cast. I've changed them to std::shared_ptr and std::make_shared. Is this acceptable?
20160724 07:13:25< vultraz> changed them locally*
20160724 07:14:06< JyrkiVesterinen> Well, I'm not actually knowledgeable about Boost. I'm familiar with C++11 and the C++ basic algorithms, but I haven't used Boost anywhere outside of Wesnoth.
20160724 07:20:28< JyrkiVesterinen> Hmm. Looking at the documentation of boost::intrusive_ptr, it's a reference counted pointer that stores the reference count in the object itself rather than in the pointer objects.
20160724 07:21:00< JyrkiVesterinen> The game engine I worked with earlier had a similar class called lang::Ptr.
20160724 07:21:57< JyrkiVesterinen> I'd cay that changing boost::intrusive_ptr to std::shared_ptr is acceptable, but then you should also remove the duplicate reference counts from the objects being referenced.
20160724 07:23:17< JyrkiVesterinen> In other words, classes like gui2::tcanvas::tshape should stop inheriting the class reference_counted_object.
20160724 07:23:26-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160724 07:29:31< vultraz> thanks :)
20160724 07:48:38-!- ggeneral [~ggeneral@37.73.196.79] has joined #wesnoth-dev
20160724 07:55:32-!- ggeneral [~ggeneral@37.73.196.79] has quit [Ping timeout: 250 seconds]
20160724 08:04:53-!- ggeneral [~ggeneral@37.73.238.251] has joined #wesnoth-dev
20160724 08:07:43-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20160724 08:08:10-!- Bonobo [~Bonobo@2001:44b8:254:3200:887f:434e:2780:1cbd] has joined #wesnoth-dev
20160724 08:15:45-!- TC02 [~quassel@venus.arosser.com] has quit [Ping timeout: 276 seconds]
20160724 08:18:15-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20160724 08:19:22-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 250 seconds]
20160724 08:28:29-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160724 08:30:48-!- ggeneral [~ggeneral@37.73.238.251] has quit [Ping timeout: 250 seconds]
20160724 08:34:25-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160724 08:34:28-!- Kwandulin [~Miranda@p200300760F60624D8CF14E5C2ED79A73.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160724 08:34:44-!- edgrey [~edgrey@178.204.157.14] has quit [Ping timeout: 258 seconds]
20160724 08:34:58-!- iceiceice [~chris@ext-74.ias.edu] has joined #wesnoth-dev
20160724 08:34:58-!- iceiceice [~chris@ext-74.ias.edu] has quit [Changing host]
20160724 08:34:58-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160724 08:35:42< iceiceice> vultraz, JyrkiVesterinen: it might not be a good idea to replace boost::intrusive_ptr with std::shared_ptr,
20160724 08:35:49< vultraz> how come?
20160724 08:36:28< iceiceice> some years ago i changed most of the places in the code to use `unit_ptr`, which is a `boost::intrusive_ptr<unit>`, where previously we were just copying units constantly
20160724 08:36:42< iceiceice> i was originally going to use std::shared_ptr and mordante was strongly opposed
20160724 08:37:06< iceiceice> because there is some overhead in std::shared_ptr for thread safety
20160724 08:37:17< iceiceice> i guess that also anura uses `boost::intrusive_ptr` for this reason
20160724 08:38:09< iceiceice> now i guess that personally i dont think its likely to matter that much, there are also some drawbacks of `boost::intrusive_ptr` and that's why it did not become standard
20160724 08:38:28< iceiceice> but consensus of past developers anyways was to avoid std::shared_ptr in busy parts of code
20160724 08:39:17< iceiceice> anyways if you just replace boost::intrusive_ptr with std::shared_ptr, you should understand that you are taking a small performance hit
20160724 08:39:30-!- Appleman1234 [~Appleman1@KD036012037132.au-net.ne.jp] has joined #wesnoth-dev
20160724 08:46:34< iceiceice> ancestral: actually, a few weeks ago i had the same issues trying to build with xcode
20160724 08:46:36< iceiceice> regarding bind
20160724 08:46:52< iceiceice> actually i wasn't using xcode though, i was just using scons from OS X command line
20160724 08:47:31< iceiceice> i think there is no problem with your project file, its just that the apple clang compiler has difficulties with the trick that wesnoth introduced to migrate to std::bind
20160724 08:47:54< iceiceice> not sure but that's my interpretation
20160724 08:48:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160724 08:52:12< vultraz> iceiceice: well, we're trying to remove cases of boost::bind, both in direct usage and and implicitly included through other boost headers
20160724 08:52:51-!- ggeneral [~ggeneral@37.73.219.92] has joined #wesnoth-dev
20160724 08:54:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160724 08:58:43-!- Kwandulin [~Miranda@p200300760F60624DA4636FF170C237E4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160724 09:02:01-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 244 seconds]
20160724 09:02:51< iceiceice> vultraz, hmm for some reason i didnt get your message
20160724 09:02:54< iceiceice> but i see it now in logs
20160724 09:04:15-!- Bonobo [~Bonobo@2001:44b8:254:3200:887f:434e:2780:1cbd] has quit [Ping timeout: 258 seconds]
20160724 09:05:45< vultraz> I wonder why in cases where boost::instrusive_prt was paired with boost::dynamic_pointer_case, when using std::shared_ptr I need to use std::static_pointer_cast
20160724 09:06:53< vultraz> s/case/cast
20160724 09:16:17 * vultraz pings iceiceice
20160724 09:16:28< vultraz> iceiceice: stop pinging me in PM and then never responding when I do, please :|
20160724 09:21:04-!- ggeneral [~ggeneral@37.73.219.92] has quit [Ping timeout: 250 seconds]
20160724 09:21:37-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20160724 09:24:30-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160724 09:29:04< iceiceice> vultraz, sorry,
20160724 09:29:09< iceiceice> let me explain in chat, i figured it out
20160724 09:29:09-!- Kwandulin [~Miranda@p200300760F60624DA4636FF170C237E4.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160724 09:29:20-!- irker605 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160724 09:32:48< vultraz> I think I may be seeing that slight performance hit you spoke of
20160724 09:32:50< vultraz> but I cannot be sure
20160724 09:37:41-!- ggeneral [~ggeneral@37.73.219.92] has joined #wesnoth-dev
20160724 09:42:25-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 1716 Yes, 366 No | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160724 09:42:59< vultraz> #60
20160724 09:44:33-!- ggeneral [~ggeneral@37.73.219.92] has quit [Ping timeout: 258 seconds]
20160724 09:44:50-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 1716 Yes, 366 No, 33 AML | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160724 09:58:39< zookeeper> maybe also tell the time, not just the day
20160724 09:59:55< JyrkiVesterinen> And the time zone, too.
20160724 10:05:24-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160724 10:05:29< vultraz_iOS> iceiceice: do you copy
20160724 10:06:46-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160724 10:07:08-!- iceiceice [~chris@ext-74.ias.edu] has joined #wesnoth-dev
20160724 10:07:08-!- iceiceice [~chris@ext-74.ias.edu] has quit [Changing host]
20160724 10:07:08-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160724 10:07:16< vultraz> iceiceice: test
20160724 10:08:39< vultraz_iOS> iceiceice: anything from my other client?
20160724 10:08:49< iceiceice> no
20160724 10:08:58< vultraz_iOS> :(
20160724 10:09:44-!- Kwandulin [~Miranda@p200300760F606279A4636FF170C237E4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160724 10:10:38-!- vultraz is now known as vultrazTEST
20160724 10:10:42< vultrazTEST> iceiceice: do you copy?
20160724 10:11:03< iceiceice> i deleted every "ignore.conf" on my system
20160724 10:11:06< iceiceice> going to restart :)
20160724 10:11:08-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Client Quit]
20160724 10:11:33-!- iceiceice [~chris@ext-74.ias.edu] has joined #wesnoth-dev
20160724 10:11:33-!- iceiceice [~chris@ext-74.ias.edu] has quit [Changing host]
20160724 10:11:33-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160724 10:12:06-!- vultrazTEST is now known as vultraz
20160724 10:12:11< vultraz> iceiceice: ping ping
20160724 10:12:17< iceiceice> ok, i think that did it
20160724 10:13:34< vultraz> iceiceice: can you indeed read me now?
20160724 10:14:44< vultraz_iOS> iceiceice:
20160724 10:15:59< vultraz> :|
20160724 10:16:31 * vultraz_iOS waves
20160724 10:16:58< loonycyborg> for some reason
20160724 10:17:06< vultraz> hm?
20160724 10:17:12< loonycyborg> but vultraz and iceiceice periodically disconnect
20160724 10:17:28< loonycyborg> I'm not surprised you're having hard time communicating
20160724 10:17:42< vultraz> my power goes out and he's trying to fix his irc client where he accidentally set me on ignore 
20160724 10:18:03< loonycyborg> why your power is going off?
20160724 10:18:16< vultraz> no idea
20160724 10:18:37< vultraz> ask the power company
20160724 10:19:32< iceiceice> ok i'll tell the strange story in channel i guess
20160724 10:20:05< iceiceice> a few dyas ago i had a wierd experience where, on some rnadom chanenl in freenode, some person i dont know tried to send me a file unsolicited
20160724 10:20:08< vultraz_iOS> iceiceice: I'm still ignored?
20160724 10:20:09< iceiceice> named like "something.exe"
20160724 10:20:14< iceiceice> no you are not ignored now i think
20160724 10:20:31< iceiceice> so i declined it, then they logged off, and i clicked to ignore them
20160724 10:20:41< iceiceice> but then my client said somtehing like "vultraz added to ignore list"
20160724 10:20:52< vultraz> Can you see this
20160724 10:21:14< iceiceice> i wasnt sure what to make of that, if it was like, vultraz had a virus, and it made some other alias on this irc channel and tried to send me a virus
20160724 10:21:29< iceiceice> or if it was like some stranger, but when they logged off, it confused my irc client and it added vultraz to ignore list instead
20160724 10:21:42< iceiceice> anyways i didnt think vultraz was actually on ignore list, but it turns out he was
20160724 10:22:00< iceiceice> but it was seriously confusing, and surprisingly hard to fix
20160724 10:22:33< vultraz> but it's fixed now
20160724 10:22:58< iceiceice> i guess if anyone i previously ignored starts spamming me i will just add them again
20160724 10:23:24< vultraz_iOS> I'm still not sure it's fixed since you aren't replying to anything I saw on the other client : p
20160724 10:24:39< loonycyborg> iceiceice: it's pointless to ignore nicks like that
20160724 10:24:47< loonycyborg> pretty sure if it sent you an exe
20160724 10:24:50< loonycyborg> it was a bot
20160724 10:25:20< iceiceice> yeah i'm only seeing vultraz_iOS
20160724 10:25:25< iceiceice> damn
20160724 10:25:29< vultraz_iOS> God dammit!
20160724 10:25:38< iceiceice> maybe i shuld do like
20160724 10:25:52< iceiceice> rm -rf ~/.xchat2 or something
20160724 10:26:19< iceiceice> that would kind of suck though
20160724 10:26:35< iceiceice> afaik i would have to reconfigure all the channels and passwords
20160724 10:26:52< vultraz_iOS> Fine, I'll just talk to you here
20160724 10:27:57< iceiceice> loonycyborg, i see, i guess i thought ignore was more robust than this
20160724 10:28:11< vultraz_iOS> Any chance you could explain the purpose of intrusive_ptr_add_ref and intrusive_ptr_release
20160724 10:29:55< iceiceice> its just some implementation detail of intrusive_ptr
20160724 10:30:12< iceiceice> http://www.boost.org/doc/libs/1_61_0/libs/smart_ptr/intrusive_ptr.html
20160724 10:30:42< vultraz_iOS> So not needed if a shared_ptr were used?
20160724 10:31:02< iceiceice> yeah
20160724 10:31:12< iceiceice> so i guess in wesnoth
20160724 10:31:14< iceiceice> and also in anura
20160724 10:31:23< iceiceice> there is some base class "shared_object" or something
20160724 10:31:28< iceiceice> that implements those two functions
20160724 10:31:50< JyrkiVesterinen> In Wesnoth the base class is reference_counted_object.
20160724 10:34:36-!- Bonobo [~Bonobo@2001:44b8:254:3200:d919:c10d:1de3:8bd3] has joined #wesnoth-dev
20160724 10:34:45< vultraz_iOS> Converting stuff to shared_ptr isn't as easy as I thought
20160724 10:35:12< iceiceice> yeah
20160724 10:35:20< iceiceice> actually
20160724 10:35:27< iceiceice> i think the "reference_counted_object" template kind of sucks
20160724 10:35:31< iceiceice> *class
20160724 10:35:37< iceiceice> it has this ugly const_cast
20160724 10:35:46< iceiceice> also it forces you to use a virtual destructor
20160724 10:36:00< vultraz_iOS> Yup I just broke wesnoth
20160724 10:36:02< iceiceice> it would probably be better to rewrite it to use crtp
20160724 10:36:09< vultraz_iOS> Can't move units anymore
20160724 10:36:17< vultraz_iOS> To use what?
20160724 10:36:26< iceiceice> CRTP is a template metaprogramming technique
20160724 10:36:34< iceiceice> https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
20160724 10:38:03< iceiceice> it would go a bit faster i think, because then not everything would need to have  a vtable
20160724 10:38:12< iceiceice> or do dynamic dispatch when it is destroyed
20160724 10:38:49< vultraz_iOS> Not sure what to do with the refcount() call in variant::refcount()
20160724 10:38:57< vultraz_iOS> Case TYPE_CALLABLE
20160724 10:38:57< iceiceice> otoh crtp is kind of advanced, i dont think wesnoth uses crtp anywhere
20160724 10:39:30< Aginor> what's this greenlight vote thin?
20160724 10:39:42< iceiceice> maybe wesnoth uses std::enable_shared_from_this, i dont remember
20160724 10:39:47< iceiceice> thats another example of crtp
20160724 10:39:53< vultraz_iOS> Since I removed the inheritance from reference_counted_object
20160724 10:40:09< vultraz_iOS> iceiceice: it does in two places
20160724 10:40:25< vultraz_iOS> Aginor: we're on steam Greenlight, it's the counter of the votes we've gotten
20160724 10:43:26< Aginor> ah, nice
20160724 10:45:42< vultraz> gahhh
20160724 10:45:46< vultraz> shared_ptr y u no be simple
20160724 10:46:09< Aginor> it is ;)
20160724 10:46:22< vultraz> well, ok
20160724 10:46:26< vultraz> wesnoth code y u no be simple
20160724 10:46:52< Aginor> old and crusty
20160724 10:46:54< vultraz> I've broken units trying to refactor boost::intrusive_ptr into std::shared_ptr
20160724 10:47:30 * Aginor disappears to gaze into his steam library before going to bed
20160724 10:47:44< vultraz> Aginor: don't forget to vote on us :)
20160724 10:50:42-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has joined #wesnoth-dev
20160724 10:51:50-!- JyrkiVesterinen [~JyrkiVest@87-100-147-187.bb.dnainternet.fi] has quit [Quit: Going somewhere]
20160724 10:53:56 * vultraz is getting into 'i have NFI what I'm doing' territory
20160724 10:55:03< vultraz> really, really should have committed the stuff I had that worked before trying to go off and do other stuff :|
20160724 10:56:17< vultraz> (for the record, converting the GUI2 uses of intrusive_ptr was pretty simple)
20160724 11:09:09-!- Duthlet [~Duthlet@dslb-188-104-247-201.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160724 11:19:38-!- Bonobo [~Bonobo@2001:44b8:254:3200:d919:c10d:1de3:8bd3] has quit [Ping timeout: 250 seconds]
20160724 11:29:22-!- TsunamiState [59b850b4@gateway/web/freenode/ip.89.184.80.180] has joined #wesnoth-dev
20160724 11:30:01-!- TsunamiState [59b850b4@gateway/web/freenode/ip.89.184.80.180] has quit [Client Quit]
20160724 11:38:46-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160724 11:45:57< vultraz> hm
20160724 11:46:01< vultraz> the main issue is with the unit_ptr
20160724 11:46:06< vultraz> gonna try reverting that 
20160724 11:46:11< vultraz> see if the remainder is fine
20160724 12:08:31< vultraz> uh... 
20160724 12:08:33< vultraz> huh
20160724 12:09:16< vultraz> units move really fast now :|
20160724 12:09:29< iceiceice> shadowm, Rhonda: i reported a bug against the gettext documentation :p
20160724 12:09:30< iceiceice> http://savannah.gnu.org/bugs/index.php?48615
20160724 12:10:18< vultraz> hm
20160724 12:10:25< vultraz> im noticing a slight performance *gain* now
20160724 12:11:33-!- irker339 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160724 12:11:33< irker339> wesnoth: Charles Dang wesnoth:boost_trimming cbd339584763 / src/ (201 files in 35 dirs): Refactor most boost pointer related stuff to use their stdlib counterparts inste https://github.com/wesnoth/wesnoth/commit/cbd3395847633bee5abab29d0de0f1f22bc094f4
20160724 12:13:48< vultraz> ok, so there's an issue with that ^, namely that units move really fast all of a sudden
20160724 12:13:59< vultraz> and I need to work on the cleanup commit
20160724 12:14:03< vultraz> for includes
20160724 12:15:09< vultraz_iOS> iceiceice: ^ if you'd like to give that a quick once-over (especially the gui2 stuff) that'd be cool
20160724 12:33:12-!- JyrkiVesterinen [~JyrkiVest@87-92-31-224.bb.dnainternet.fi] has joined #wesnoth-dev
20160724 12:34:41-!- Bonobo [~Bonobo@2001:44b8:254:3200:d919:c10d:1de3:8bd3] has joined #wesnoth-dev
20160724 12:47:13-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has joined #wesnoth-dev
20160724 12:47:14< travis-ci> wesnoth/wesnoth#9922 (boost_trimming - cbd3395 : Charles Dang): The build was broken.
20160724 12:47:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/146981928
20160724 12:47:14-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has left #wesnoth-dev []
20160724 12:53:57-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 276 seconds]
20160724 12:56:18-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160724 13:29:54-!- Kwandulin [~Miranda@p200300760F606279A4636FF170C237E4.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160724 13:47:33-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 1839 Yes, 412 No, 33 AML | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160724 13:47:47< vultraz> #57
20160724 13:48:28-!- mjs-de [~mjs-de@p508C8855.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160724 13:51:23-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160724 13:55:38-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has quit [Ping timeout: 258 seconds]
20160724 13:59:46-!- Kwandulin [~Miranda@p200300760F606279D14165A6CAC0D1B5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160724 14:01:46-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has joined #wesnoth-dev
20160724 14:34:25-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160724 14:36:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160724 14:38:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160724 14:39:34-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160724 14:42:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160724 14:49:00-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160724 14:49:06-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has quit [Ping timeout: 250 seconds]
20160724 14:51:28-!- mjs-de [~mjs-de@p508C8855.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20160724 14:57:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160724 14:58:29-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20160724 14:59:37-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160724 15:11:29< vultraz> huh
20160724 15:11:44< vultraz> you can't use make_shared directly on a class with virtual members?
20160724 15:18:34< vultraz> oh, wait, no, I just had the wrong template type
20160724 15:30:45< irker339> wesnoth: Charles Dang wesnoth:boost_trimming c0c08f92b7dc / src/ (193 files in 37 dirs): Refactor most boost pointer related stuff to use their stdlib counterparts https://github.com/wesnoth/wesnoth/commit/c0c08f92b7dc8dbcae353c8133e0a51d59c8fd27
20160724 15:30:48< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 5850d1d68a99 / src/gui/ (30 files in 4 dirs): Refactored GUI2's uses of boost::intrusive_ptr https://github.com/wesnoth/wesnoth/commit/5850d1d68a99d373c4ad3d2ec31712011b9e0ba4
20160724 15:30:51< irker339> wesnoth: Charles Dang wesnoth:boost_trimming efcca8f6a21d / src/ (11 files in 4 dirs): Refactored formula's use of boost::intrusive_ptr https://github.com/wesnoth/wesnoth/commit/efcca8f6a21dfe1ad96ebcf5b60c853fcf0c0e80
20160724 15:30:54< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 13de53240893 / src/gui/dialogs/gamestate_inspector.cpp: Fixup 5850d1d68a https://github.com/wesnoth/wesnoth/commit/13de532408934a50de5be7dbe4b8ebeae79dde65
20160724 15:31:13-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160724 15:31:34< vultraz_iOS> iceiceice: force pushed and split the commit like you advised
20160724 15:33:30< celticminstrel> Argh! Why couldn't you have done that two hours ago! :(
20160724 15:33:57< celticminstrel> Uhhh, why are you changing intrusive_ptr?
20160724 15:34:31< vultraz> celticminstrel: what happened two hours ago?
20160724 15:34:42< celticminstrel> I pulled.
20160724 15:34:52< celticminstrel> Actually it was more like an hour and a half ago.
20160724 15:35:20< vultraz> I was working on it at the time :P
20160724 15:35:28< celticminstrel> Sigh.
20160724 15:35:35< celticminstrel> Hopefully pull --rebase will work.
20160724 15:35:46< celticminstrel> But more seriously, why are you changing intrusive_ptr?
20160724 15:37:00< vultraz> eh, I got caught up with changing things
20160724 15:37:10< vultraz> if it really does nothing those commits can be removed
20160724 15:37:52< vultraz> for the record, I still appear to have broken accelerated speed :|
20160724 15:37:54-!- Bonobo [~Bonobo@2001:44b8:254:3200:d919:c10d:1de3:8bd3] has quit [Ping timeout: 250 seconds]
20160724 15:38:01< celticminstrel> What caused that?
20160724 15:38:02< vultraz> units now rush across the map
20160724 15:38:05< vultraz> I don't know
20160724 15:38:20< celticminstrel> Well, whatever. That sort of thing is why this is a branch.
20160724 15:40:01< vultraz> with the formulas I was hoping to get rid of the custom ref counting
20160724 15:40:08< celticminstrel> intrusive_ptr is not equivalent to shared_ptr, and I don't know why it was chosen instead of shared_ptr. There might have been a good reason.
20160724 15:40:08< vultraz> but apparently deeper refactoring is needed to do that
20160724 15:40:23< vultraz> iceiceice says there is a slight performance gain
20160724 15:40:42< vultraz> with intrusive_ptr since it doesn't have shared_ptr's thread-safe overhead
20160724 15:41:04< iceiceice> celticminstrel, some game devs really don't like std::shared_ptr
20160724 15:41:31< iceiceice> i think its mostly just a taste thing
20160724 15:41:37< celticminstrel> In what way were you unable to remove the custom refcounting?
20160724 15:42:06< vultraz> eh, wait
20160724 15:42:17< vultraz> was that for unit_ptr?
20160724 15:42:19< celticminstrel> You didn't remove the refcount() function though.
20160724 15:42:28< JyrkiVesterinen> iceiceice: Inertia plays a role as well in custom refcounting of some games.
20160724 15:42:37< celticminstrel> Huhwhat?
20160724 15:42:38< vultraz> I did remove some from the formula code
20160724 15:42:46< iceiceice> yeah thats true also
20160724 15:42:54< vultraz> celticminstrel: I also tried to touch unit_ptr. Huge mess, so I reverted.
20160724 15:43:17< JyrkiVesterinen> If custom refcounting is used, there must be a policy that all objects must support it (inherit a class that supports refcounting).
20160724 15:43:23< vultraz> celticminstrel: the use of intrusive_ptr in units seems to feature much deeper custom refcounting than the formula code
20160724 15:43:30< celticminstrel> Yeah, formula does inherit such a class.
20160724 15:43:43-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has joined #wesnoth-dev
20160724 15:43:44< travis-ci> wesnoth/wesnoth#9923 (boost_trimming - 13de532 : Charles Dang): The build is still failing.
20160724 15:43:44< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147005887
20160724 15:43:44-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has left #wesnoth-dev []
20160724 15:43:49< JyrkiVesterinen> And in that case, of course everyone is going to use intrusive_ptr or equivalent instead of std::shared_ptr.
20160724 15:44:02< iceiceice> i think i decided not to inherit from the reference_counted_object
20160724 15:44:07< iceiceice> when i did class unit
20160724 15:44:12< iceiceice> X many years ago
20160724 15:44:13< iceiceice> because
20160724 15:44:18< JyrkiVesterinen> And the only thing that could change the situation would be a full 180-degree change of policy. Not something that would be done in a whim.
20160724 15:44:20< iceiceice> it caused an annoying problem
20160724 15:44:33< iceiceice> in C++ you often want to forward declare a type
20160724 15:44:37< iceiceice> and manipulate pointers to it
20160724 15:44:43< iceiceice> using the incomplete definition
20160724 15:44:51< iceiceice> if you have some code that is just moving unit pointers around
20160724 15:44:54< iceiceice> it shouldn't need to include unit
20160724 15:44:59< vultraz> celticminstrel: perhaps the formula case is good as-is, as long as I remove refcount()?
20160724 15:45:01< iceiceice> and back in the day including unit meant including like a ton of code
20160724 15:45:03< vultraz> s/case/commit
20160724 15:45:09< iceiceice> like all of SDL and formula and animations
20160724 15:45:22< celticminstrel> JyrkiVesterinen: So you're implying that this formula case and the GUI2 case aren't something that should be changed?
20160724 15:45:25< iceiceice> so i wanted you to be able to manipulate unit_ptr without including all of unit
20160724 15:45:28< iceiceice> but
20160724 15:45:32< celticminstrel> I personally have no preference about the refcounting though.
20160724 15:45:35< iceiceice> in C++ inheritance cannot be forward declared
20160724 15:45:44< iceiceice> so the "reference_counted_object" thing
20160724 15:45:56< iceiceice> forces you to fully include the type whenever you manipulate a ref counted pointer to it
20160724 15:46:00< JyrkiVesterinen> celticminstrel: No. I was talking about the general case. Why "some game devs really don't like std::shared_ptr".
20160724 15:46:11< celticminstrel> iceiceice: Ah, yeah, that makes a lot of sense.
20160724 15:46:12< iceiceice> if you don't care how long it takes to compile your code, then thats fine
20160724 15:46:23< iceiceice> but imo the reference_counted_object thing kind of sucks for that reason
20160724 15:46:45< JyrkiVesterinen> It's not that we dislike it. It's that if someone has already decided to use custom reference counting, then it's highly unlikely that a game project would give it up.
20160724 15:47:46< JyrkiVesterinen> We don't have an "every object must support custom reference counting" rule. It can go either way in this project.
20160724 15:47:47< celticminstrel> vultraz: You said you removed some from the formula code, does that mean you also left some?
20160724 15:47:59< celticminstrel> I feel like you did miss some things though...
20160724 15:48:03< vultraz> celticminstrel: you just said I left refcount()
20160724 15:48:09< celticminstrel> Besides that.
20160724 15:48:28< celticminstrel> (Actually, refcount() might be implementable even with shared_ptr.)
20160724 15:48:57< vultraz> there's a case in refcount() that I made just return 0 
20160724 15:49:13< vultraz> TYPE_CALLABLE or something
20160724 15:49:15< iceiceice> vultraz i guess if i were you, i would probably just leave all the formula code alone
20160724 15:49:31< vultraz> iceiceice: can you read me from here?
20160724 15:49:32< iceiceice> iirc there's not that many unit tests of it
20160724 15:49:35< iceiceice> yeah i can read you from there
20160724 15:49:39< vultraz> whoot!
20160724 15:49:45< celticminstrel> TYPE_CALLABLE is poorly named - it's actually WFL's object type.
20160724 15:49:53< iceiceice> yeah i complained to dave about that once :p
20160724 15:49:59< vultraz> wait, wha?
20160724 15:50:03< celticminstrel> I think it's called "callable" because you can "call a formula on it".
20160724 15:50:43< iceiceice> yeah it totally doesn't make sense
20160724 15:50:49< iceiceice> callable in java means an object with a calloperator
20160724 15:50:50< celticminstrel> iceiceice: There are actually some formula unit tests, though whether there are enough, I dunno.
20160724 15:51:02< iceiceice> callable in C++ means, anything you can use with the call syntax
20160724 15:51:36< iceiceice> the formula callable, yeah its like formula object or something
20160724 15:51:38< celticminstrel> Yeah, same in Lua.
20160724 15:51:57< celticminstrel> But in formula it's a bit different. I think I called it "object" in the wiki documentation though.
20160724 15:52:04< iceiceice> thats good
20160724 15:52:21< iceiceice> when i was working on anura, dave agreed that its a bad name
20160724 15:52:29< iceiceice> but in anura they actually have a different thing already called formula object
20160724 15:52:34< iceiceice> so they cant call formula callable that
20160724 15:52:46< iceiceice> and its a huge amount of work to change the name i guess
20160724 15:52:52< iceiceice> idk, he should change it imo
20160724 15:53:02< iceiceice> i guess they all already got used to it
20160724 15:53:07< celticminstrel> vultraz: For example, the reference-counted list and vector wrapper still seem to be present?
20160724 15:53:19< celticminstrel> ^map and vector
20160724 15:53:50< vultraz> celticminstrel: where?
20160724 15:53:55< celticminstrel> In formula.
20160724 15:54:13< iceiceice> vultraz, i think this commit https://github.com/wesnoth/wesnoth/commit/c0c08f92b7dc8dbcae353c8133e0a51d59c8fd27 is mostly good
20160724 15:54:15< iceiceice> but
20160724 15:54:29< iceiceice> i guess i would get rid of the stuff in formula manager also
20160724 15:54:44< vultraz> hm?
20160724 15:54:47< iceiceice> i think you cant change formula_callable_ptr to a shared_ptr
20160724 15:54:48< celticminstrel> You mean the unit formula manager?
20160724 15:54:56< iceiceice> unless you change the whole formula callable type to use shared_ptr
20160724 15:54:59< iceiceice> or you could get a double delete
20160724 15:55:01< celticminstrel> formula_callable_ptr would be an intrusive_ptr, right?
20160724 15:55:07< vultraz> uhh
20160724 15:55:10< vultraz> you guys are confusing me
20160724 15:57:26< celticminstrel> I'm not 100% sure what he's talking about either.
20160724 15:57:49< iceiceice> i'll send a link
20160724 15:58:14< iceiceice> https://github.com/wesnoth/wesnoth/commit/c0c08f92b7dc8dbcae353c8133e0a51d59c8fd27#commitcomment-18371528
20160724 16:00:10< vultraz> it compiles, yes
20160724 16:00:39< iceiceice> ok then i'm confused
20160724 16:03:10< celticminstrel> vultraz: Did you miss when I said that boost::scoped_ptr should probably become const std::unique_ptr?
20160724 16:03:29< vultraz> oh
20160724 16:03:45< vultraz> I didn't make it const
20160724 16:03:49 * celticminstrel is noting each case in the diff on that page.
20160724 16:04:11< celticminstrel> Probably should, unless that fails to compile.
20160724 16:04:27< vultraz> celticminstrel: should every single case of unique_ptr be const?
20160724 16:04:31< vultraz> if so I can just mass find/replace
20160724 16:04:38< celticminstrel> No, only the ones that were converted from scoped_ptr.
20160724 16:05:08< celticminstrel> (Well, and any that already were const.)
20160724 16:05:15 * vultraz groans
20160724 16:05:44< celticminstrel> Yeah, there are surprisingly a lot of them.
20160724 16:06:39< vultraz> you still noting every case?
20160724 16:06:41< celticminstrel> Yeah.
20160724 16:06:56< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 86b69d6db943 / / (7 files in 5 dirs): Remove custom ref counting header (no longer necessary after efcca8f6a21) https://github.com/wesnoth/wesnoth/commit/86b69d6db943f42d9821b18eb781b180f4b12f10
20160724 16:06:56< celticminstrel> I can stop if you're going to redo the whole commit or something though.
20160724 16:07:26< iceiceice> celticminstrel, sometimes its annoying to declare class members as const
20160724 16:07:40< celticminstrel> True.
20160724 16:07:41< iceiceice> because then it doesn't get a proper move constructor
20160724 16:07:46< celticminstrel> Oh.
20160724 16:08:02< iceiceice> i guess in most cases it probably doesn't matter here
20160724 16:08:08< celticminstrel> Well, I think most of our classes don't need a move constructor though...
20160724 16:09:11< vultraz> so should I apply the cases of const-ness as celticminstrel is suggesting or not?
20160724 16:09:38< celticminstrel> Some of them are local variables in functions.
20160724 16:09:45< celticminstrel> Those definitely should be const.
20160724 16:10:04< celticminstrel> The class ones probably should be too, but maybe it's not so important.
20160724 16:10:16< vultraz> I'm going to go through your list and just do every one you listed
20160724 16:10:36< celticminstrel> If any one of them causes compiler errors, just drop that one.
20160724 16:10:47< vultraz> tell me when you're done
20160724 16:12:13< celticminstrel> The reasoning for this is thus. boost::scoped_ptr is supposedly intended to guarantee that the pointer is freed when the scope ends.
20160724 16:12:36< celticminstrel> If you use std::unique_ptr, this is not guaranteed, because some other unique_ptr could have seized control.
20160724 16:12:48< celticminstrel> But if it's const std::unique_ptr, then that's not possible because, well, it's const.
20160724 16:14:36< celticminstrel> Firefox is now spinning the beachball.
20160724 16:17:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160724 16:17:44< celticminstrel> Again, if making one of them const causes a compiler error, just skip that one.
20160724 16:19:58-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has joined #wesnoth-dev
20160724 16:19:59< travis-ci> wesnoth/wesnoth#9924 (boost_trimming - 86b69d6 : Charles Dang): The build is still failing.
20160724 16:19:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147010830
20160724 16:19:59-!- travis-ci [~travis-ci@ec2-54-87-94-81.compute-1.amazonaws.com] has left #wesnoth-dev []
20160724 16:24:44< celticminstrel> Okay, done.
20160724 16:30:19< celticminstrel> In the tod_manager case I don't think bind was even needed.
20160724 16:30:27< celticminstrel> Testing that now.
20160724 16:31:06-!- Kwandulin [~Miranda@p200300760F606279D14165A6CAC0D1B5.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160724 16:33:59-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has joined #wesnoth-dev
20160724 16:40:01< vultraz> DONE
20160724 16:40:08< vultraz> celticminstrel: see my two replies
20160724 16:40:51< vultraz> specifically where you pointed out a shared_ptr
20160724 16:41:01< vultraz> also, seems that one formula change snuck into this commit
20160724 16:41:19< vultraz> should probably split it now :/
20160724 16:41:33< vultraz> or maybe tomorrow
20160724 16:41:37< celticminstrel> There were two or three instances of that including the one iceiceice commented on.
20160724 16:41:48< vultraz> wha?
20160724 16:41:54< celticminstrel> All close together in the diff, at least.
20160724 16:42:02 * vultraz groans
20160724 16:42:05< vultraz> it's almost 4 am
20160724 16:42:09< vultraz> where 
20160724 16:42:43< celticminstrel> I think they're just above iceiceice's comment.
20160724 16:43:36< vultraz> ok, yes
20160724 16:43:40< vultraz> you said I needed to const
20160724 16:43:44< vultraz> a shared_ptr
20160724 16:43:45< vultraz> is that right
20160724 16:44:29< celticminstrel> No, that's not right. I wasn't reading closely, just looking for places where more than just boost->std changed.
20160724 16:44:40< vultraz> ok
20160724 16:44:48< celticminstrel> I replied there as well.
20160724 16:44:56< vultraz> gah
20160724 16:44:59< vultraz> so many errors :(
20160724 16:45:07< vultraz> code doesn't like being constified
20160724 16:45:20< celticminstrel> Hmm?
20160724 16:46:03< vultraz> having to revert a lot of these const additions
20160724 16:46:40< celticminstrel> So anyway, there are four lines in the diff that should be moved to the formula commit. Two in units/formula_manager.cpp, one in units/formula_manager.hpp, and one in units/filter.cpp.
20160724 16:46:58< celticminstrel> The ones you need to revert, are they at class scope or function scope?
20160724 16:47:22< vultraz> uh
20160724 16:47:23< vultraz> both
20160724 16:47:28< vultraz> most function
20160724 16:47:32< vultraz> but at least 2 cases in unit.hpp
20160724 16:47:50< celticminstrel> Hmm, I'd prefer not to revert function-scope cases... where are these?
20160724 16:47:59 * vultraz groans
20160724 16:48:13< vultraz> about.cpp:209
20160724 16:48:31< vultraz> actions/undo_action:96
20160724 16:48:44< vultraz> addons/manager_ui:610
20160724 16:49:16< vultraz> units/unit.hpp:526, 528
20160724 16:49:36< vultraz> display.hpp:662
20160724 16:50:41< celticminstrel> In about.cpp, you can indent lines 209-222 in a bare block and remove the reset. This should work even when it's const.
20160724 16:50:42< vultraz> celticminstrel: can you remove the rest of the refcount stuff I forgot (formula::refcount()) and stuff
20160724 16:50:50< vultraz> and then tomorrow i'll squash
20160724 16:50:56< vultraz> I can't do it now
20160724 16:51:00< vultraz> I need to finish this and get sleep
20160724 16:51:09< celticminstrel> I wasn't talking about formula::refcount(), actually. I was talking about the WFL function refcount(). Though I guess they're related.
20160724 16:51:25< vultraz> whatever it is can you deal with it!
20160724 16:51:31< celticminstrel> Probably.
20160724 16:51:38< vultraz> thank you
20160724 16:51:48< celticminstrel> Gah, beachball again.
20160724 16:51:55< celticminstrel> And it ends just as I finish saying it.
20160724 16:52:23< vultraz> editor/controller/editor_controller.hpp:242
20160724 16:53:05< vultraz> editor/map/map_context.hpp:488
20160724 16:53:18< celticminstrel> actions/undo_action.cpp cannot be const.
20160724 16:53:48< vultraz> editor_controller:246
20160724 16:54:26< vultraz> '':244
20160724 16:55:06< vultraz> editor/toolkit/editor_toolkit.hpp:88
20160724 16:55:38< celticminstrel> Sorry, I initially just marked every instance without looking closely at how it's used.
20160724 16:56:27< vultraz> game_board.hpp:59
20160724 16:57:43< celticminstrel> addon/manager_ui.cpp:610 is kinda convoluted so it's probably easiest just to leave it non-const.
20160724 16:58:04< vultraz> celticminstrel: also if you commit the refcount stuff remove the header from xcode too
20160724 16:58:08< vultraz> i already removed it from cb
20160724 16:58:33< celticminstrel> Right.
20160724 16:59:10< celticminstrel> Should also ask wedge009 to remove it from MSVC (in case he hasn't been paying attentin, this is in the boost_trimming branch).
20160724 16:59:45< vultraz> game_initialization/create_engine.hpp:88
20160724 17:00:34< vultraz> game_initialization/create_engine.hpp:307
20160724 17:00:59< celticminstrel> The ones in units/unit.hpp are class scope, so let's just leave them non-const.
20160724 17:01:09< celticminstrel> (Lines 526/528)
20160724 17:01:10< vultraz> game_initialization/create_engine.hpp:309
20160724 17:01:54< celticminstrel> Same for the halo manager in display.hpp
20160724 17:02:01< vultraz> game_initialization/create_engine.cpp:998
20160724 17:03:05< vultraz> your suggestion of plain scope for about.cpp  doesn't work
20160724 17:03:31< vultraz> game_initialization/multiplayer_ui.hpp:258
20160724 17:04:57< vultraz> game_state.hpp:48
20160724 17:05:31< celticminstrel> The editor ones are again class scope, so let's just leave them non-const.
20160724 17:05:40< celticminstrel> (Incidentally, what sort of errors do those give you?)
20160724 17:06:25< vultraz> game_state.hpp:50
20160724 17:06:37< vultraz> they vary
20160724 17:06:49< vultraz> sometime sstuff about passing 'this' discards qualifiers or something
20160724 17:06:52< celticminstrel> I'm not seeing the ones you listed in create_engine. Maybe they're a result of the typedef at line 42?
20160724 17:07:13< celticminstrel> In which case I guess they can be ignored probably.
20160724 17:07:19< vultraz> wha
20160724 17:07:23< celticminstrel> (ie make that not const)
20160724 17:07:36< celticminstrel> Thinking about it, making that const was probably a bad idea in the first place.
20160724 17:07:56< celticminstrel> Oh wait, I do have the one at line 998 though. Hmm.
20160724 17:08:14< celticminstrel> I think that one should stay const, let's see if that's actually possible...
20160724 17:08:32< vultraz> dialogs/loadscreen.hpp:63
20160724 17:08:46< celticminstrel> Yeah okay, it's not, because there's no guarantee the map will exist.
20160724 17:09:28< celticminstrel> The multiplayer_ui one can be non-const.
20160724 17:09:37< celticminstrel> Most of the ones you're posting are at class scope.
20160724 17:09:42< vultraz> yes
20160724 17:10:10< celticminstrel> The game_state ones that cause problems can also be non-const.
20160724 17:10:48< celticminstrel> Loadscreen too.
20160724 17:11:01< celticminstrel> So, what errors did you get with a plain scope in about.cpp?
20160724 17:11:15< vultraz> dialogs/loadscreen.hpp:64
20160724 17:11:21< vultraz> celticminstrel: stuff not declared
20160724 17:11:25< celticminstrel> So far that's the only one you've posted that actually seems like it could stay const.
20160724 17:11:28< celticminstrel> What stuff?
20160724 17:11:32< celticminstrel> Where?
20160724 17:13:29< vultraz> log_windows.cpp:441
20160724 17:13:56< celticminstrel> That's at global scope, so let's leave it non-const.
20160724 17:15:13< vultraz> play_controller.hpp:309
20160724 17:15:39< celticminstrel> I guess that can stay non-const.
20160724 17:17:18< vultraz> play_controller.hpp:337
20160724 17:17:21< vultraz> 327*
20160724 17:17:36< celticminstrel> How many more are coming?
20160724 17:18:49< vultraz> dunno
20160724 17:18:54< celticminstrel> :|
20160724 17:19:16< celticminstrel> So far the only one I think should stay const is the one in about.cpp.
20160724 17:19:21< vultraz> playmp_controller:124
20160724 17:19:34< celticminstrel> ...well, I think a few others should too, but for them it's impossible due to how the code flows.
20160724 17:20:21< celticminstrel> That one could stay const if the following conditional is merged into the declaration...
20160724 17:20:39< vultraz> oh, heh, now the 337 from above in play_controller.hpp is now an issue
20160724 17:21:44< celticminstrel> Let's drop that const.
20160724 17:21:53< celticminstrel> I wonder how many will actually be left once this is over.
20160724 17:22:21< celticminstrel> So far I have two that give errors that I think should be kept const.
20160724 17:23:01< vultraz> play_controller.hpp:332
20160724 17:23:12< celticminstrel> Drop const
20160724 17:23:35< vultraz> still not sure what you mean by [04:20:20]	celticminstrel	That one could stay const if the following conditional is merged into the declaration...
20160724 17:24:00< celticminstrel> Some of the class scope ones could maybe be kept const with some code changes, but I don't feel like looking through the whole class to see how they're used... >_>
20160724 17:24:16< celticminstrel> What I meant was turn the if statement into a ternary operator passed to the unique_ptr constructor.
20160724 17:24:25< celticminstrel> (The "else" value would of course be nullptr.)
20160724 17:25:05< vultraz> play_controller.hpp:320
20160724 17:25:18< celticminstrel> Meh.
20160724 17:27:10< vultraz> play_controller.hpp:314
20160724 17:27:29< celticminstrel> Meh
20160724 17:28:41-!- ggeneral [~ggeneral@46.211.1.141] has joined #wesnoth-dev
20160724 17:28:47< celticminstrel> I should go eat...
20160724 17:31:09< vultraz> 	const std::unique_ptr<countdown_clock> timer = saved_game_.mp_settings().mp_countdown
20160724 17:31:11< vultraz>         ? new countdown_clock(current_team())
20160724 17:31:12< vultraz>         : nullptr;
20160724 17:31:16< vultraz> is this what you meant
20160724 17:31:30< celticminstrel> Pretty much, though I was envisioning it parenthesized rather than with =
20160724 17:31:36< celticminstrel> They should be equivalent though.
20160724 17:31:54< vultraz> wait, no, that doesn't build
20160724 17:31:59< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\playmp_controller.cpp|126|error: conversion from 'countdown_clock*' to non-scalar type 'const std::unique_ptr<countdown_clock>' requested|
20160724 17:32:18< celticminstrel> Then use the parentheses like I said.
20160724 17:32:36< celticminstrel> Or braces would work, I guess.
20160724 17:33:04< vultraz> replay_controller.hpp:85
20160724 17:33:28< celticminstrel> I guess that one doesn't matter.
20160724 17:33:52< zookeeper> so does all this mean that no release today? :p
20160724 17:34:07< vultraz> play_controller.hpp:328
20160724 17:34:12< vultraz> zookeeper: this is a seperate branch
20160724 17:34:23< celticminstrel> Good question, what exactly is happening with the expected release?
20160724 17:34:35< vultraz> I really wanted that overlay bug fixed...
20160724 17:34:51< celticminstrel> If it's not a blocker you can list it in "known bugs".
20160724 17:35:04< celticminstrel> Oh right, did ancestral tell you yet which Mac bugs are fixed?
20160724 17:35:10< vultraz> not yet
20160724 17:35:30< celticminstrel> But, you don't need that for tagging, only for making the announcement; and making the announcement comes a bit later.
20160724 17:35:45< vultraz> I'll see about the release tomorrow
20160724 17:35:47< vultraz> (for me)
20160724 17:35:51< vultraz> well
20160724 17:35:53< vultraz> today
20160724 17:35:57< zookeeper> vultraz, oh, right.
20160724 17:36:18< celticminstrel> vultraz: So from our perspective, tonight, right?
20160724 17:36:21< vultraz> celticminstrel: so why did the parens work for that thing but not =?
20160724 17:36:24< vultraz> celticminstrel: I guess, yeah
20160724 17:36:45< celticminstrel> I don't remember all the subtleties of C++ initialization, sorry.
20160724 17:37:03< vultraz> playsingle_controller.hpp:100
20160724 17:37:11-!- ggeneral [~ggeneral@46.211.1.141] has quit [Read error: Connection reset by peer]
20160724 17:37:56< celticminstrel> I suppose that one doesn't matter.
20160724 17:38:05< celticminstrel> Was vultraz in charge of tagging, or was that loonycyborg?
20160724 17:38:16< vultraz> loonycyborg does releases
20160724 17:38:22< vultraz> I guess I tag
20160724 17:38:29-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20160724 17:38:46< celticminstrel> You know how to do that, right?
20160724 17:38:58< vultraz> game_lua_kernel.cpp:3780
20160724 17:38:59< vultraz> yes
20160724 17:39:04< celticminstrel> 'kay
20160724 17:39:10< vultraz> I think loonycyborg might have done it last time, tho..
20160724 17:39:15< vultraz> maybe I'll let him do it
20160724 17:39:37< vultraz> scripting/plugins/manager.hpp:73
20160724 17:39:58< celticminstrel> The game_lua_kernel one should probably be left non-const since it's a typedef.
20160724 17:40:14< celticminstrel> Though, I feel like it's something that generally should be const...
20160724 17:40:18< celticminstrel> I dunno...
20160724 17:40:57< vultraz> blagh
20160724 17:40:59< celticminstrel> Plugins manager might be better const too...
20160724 17:41:03< vultraz> now im getting an error i cant find the cause of
20160724 17:41:14< celticminstrel> You could get some sleep and fnish tomorrow maybe?
20160724 17:41:52< vultraz> no, I need to push this so you can commit stuff
20160724 17:42:00-!- esr [~esr@wesnoth/developer/esr] has quit [Quit: WeeChat 1.3]
20160724 17:42:25< celticminstrel> I can still commit stuff and rebase if I have to, but if you want to get it pushed, go for it?
20160724 17:43:06< vultraz> oh yeah
20160724 17:43:11< vultraz> it's that mutable stuff
20160724 17:43:30< celticminstrel> Oh yeah, I thought maybe that needed to be non-const since it was mutable.
20160724 17:43:58< vultraz> gah
20160724 17:44:02< vultraz> still this one error..
20160724 17:44:11< celticminstrel> So, only one error left?
20160724 17:45:19< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\scripting\plugins\manager.cpp|107|error: passing 'const std::unique_ptr<application_lua_kernel::thread>' as 'this' argument discards qualifiers [-fpermissive]|
20160724 17:45:21< vultraz> WHY IS THIS HERE
20160724 17:45:56< celticminstrel> Huh?
20160724 17:46:22< celticminstrel> I guess you need to drop the const in plugins/manager.cpp...?
20160724 17:46:31< vultraz> oh yeah
20160724 17:46:33< vultraz> that
20160724 17:47:00< vultraz> terrain/filter.hpp:88
20160724 17:49:17< vultraz> units/animation_componenet.hpp:113
20160724 17:49:38-!- Kwandulin [~Miranda@p200300760F60627931013152813815EC.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160724 17:51:43< vultraz> units/udisplay.cpp:808/809
20160724 17:52:14< vultraz> video.hpp:217
20160724 17:54:45< celticminstrel> I guess those can be non-const.
20160724 17:54:50< celticminstrel> All five of them.
20160724 17:55:36< vultraz> god damn my slow computer
20160724 17:56:50< celticminstrel> Me too. :/
20160724 18:02:08< vultraz> unit.hpp:527
20160724 18:06:32< celticminstrel> There were two header files missing a <string> include.
20160724 18:08:15< vultraz> wat is this
20160724 18:08:25< celticminstrel> ?
20160724 18:08:28< vultraz> C:\TDM-GCC-32\lib\gcc\mingw32\5.1.0\include\c++\bits\move.h|185|error: use of deleted function 'std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = unit_formula_manager; _Dp = std::default_delete<unit_formula_manager>]'|
20160724 18:08:32< vultraz> why is this happening
20160724 18:08:41< loonycyborg> vultraz: I think I should do the tagging
20160724 18:08:52< loonycyborg> there are steps that need to be done before it
20160724 18:09:00< vultraz> loonycyborg: I know, but you can do it
20160724 18:09:02< celticminstrel> Trying to copy a unique_ptr which is non-copyable.
20160724 18:09:32< vultraz> oh, unit.hpp:473
20160724 18:09:44< celticminstrel> Is that the cause?
20160724 18:10:02< vultraz> think so yes
20160724 18:10:22< celticminstrel> Pretty sure that wouldn't be caused by the const though.
20160724 18:10:25< vultraz> it was being called in swap() or something
20160724 18:10:56< celticminstrel> swap() doesn't need to copy anything though.
20160724 18:13:12< vultraz> swap(formula_man_, o.formula_man_);
20160724 18:13:14< vultraz> i duunno
20160724 18:13:17< vultraz> it just happened
20160724 18:13:21< vultraz> i dont question
20160724 18:13:33< celticminstrel> That should move them rather than copy them...
20160724 18:14:19< celticminstrel> Hmm, maybe it is caused by const - if it's const, it can't be moved or copied, so neither specialization of swap would appliy.
20160724 18:14:22< celticminstrel> ^apply
20160724 18:15:28-!- ggeneral [~ggeneral@46.211.114.19] has joined #wesnoth-dev
20160724 18:15:33< vultraz> same problem for unit.hpp:516
20160724 18:16:15< celticminstrel> Hmm, given that there's a swap(), I guess all the ones in unit.hpp should be non-const.
20160724 18:17:41< celticminstrel> Except for the one that already was (line 47).
20160724 18:17:46< celticminstrel> Already was const, I mean.
20160724 18:19:55-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160724 18:21:14< loonycyborg> uff pot-update failed
20160724 18:21:26< loonycyborg> seems there's a stray " in data/english.cfg
20160724 18:22:00< vultraz> whiteboard/manager.hpp:227
20160724 18:23:43< loonycyborg> celticminstrel: can you take a look at data/english.cfg:55?
20160724 18:23:51< loonycyborg> that " seems erroneous to me
20160724 18:23:56< vultraz> whiteboard/manager.hpp:224
20160724 18:27:43< vultraz> whiteboard/move.hpp:104
20160724 18:28:12< vultraz> whiteboard/move.hpp:124
20160724 18:29:47< vultraz> thread.hpp:245
20160724 18:30:11< vultraz> server.hpp:115
20160724 18:30:57< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 8c13f4e57cd0 / src/ (30 files in 15 dirs): Const-ified eligible std::unique_ptrs https://github.com/wesnoth/wesnoth/commit/8c13f4e57cd0fa6b2fb6b7a268b8249a07e837c0
20160724 18:31:02< vultraz> celticminstrel: ^^ DONE. You can do whatever you want with about.cpp
20160724 18:31:06< vultraz> now i am OFF
20160724 18:31:08< vultraz> to get some sleep
20160724 18:32:18< celticminstrel> Bye.
20160724 18:33:26< irker339> wesnoth: Celtic Minstrel wesnoth:master 220a85377dec / data/english.cfg: Fix extraneous quote https://github.com/wesnoth/wesnoth/commit/220a85377dec49c93bf06d0d7a308602a50d1b8c
20160724 18:33:42< celticminstrel> Kinda surprised that failed the pot-update though...
20160724 18:34:02< celticminstrel> Aren't we using the python wmlxgettext?
20160724 18:34:21< celticminstrel> That quote was within <<>> so should have been protected. (But was still wrong.)
20160724 18:35:25-!- ggeneral [~ggeneral@46.211.114.19] has quit []
20160724 18:44:41-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has joined #wesnoth-dev
20160724 18:44:42< travis-ci> wesnoth/wesnoth#9926 (boost_trimming - 8c13f4e : Charles Dang): The build is still failing.
20160724 18:44:42< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147030456
20160724 18:44:42-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has left #wesnoth-dev []
20160724 18:57:16< loonycyborg> celticminstrel: wmlxgettext itself didn't fail
20160724 18:57:27< loonycyborg> but it faithfully forwarded that "
20160724 18:57:35< loonycyborg> which made them unbalanced
20160724 18:57:42< loonycyborg> so msgcat barfed
20160724 18:58:11< celticminstrel> Sounds like a bug in wmlxgettext still...
20160724 19:05:28-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160724 19:05:29-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160724 19:11:27-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160724 19:49:18< celticminstrel> BTW, we've done the basic sanity-check that the game works, right?
20160724 19:50:28< celticminstrel> Only asking because an insufficient sanity-check was the reason for no 1.13.3.
20160724 19:53:56-!- Kwandulin [~Miranda@p200300760F60627931013152813815EC.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160724 19:54:46-!- JyrkiVesterinen [~JyrkiVest@87-92-31-224.bb.dnainternet.fi] has quit [Quit: .]
20160724 19:59:09< loonycyborg> celticminstrel: you can do a check yourself
20160724 20:00:28< celticminstrel> Well, I'm on a different branch right now, but I guess I could.
20160724 20:01:56-!- mjs-de [~mjs-de@x4db6b606.dyn.telefonica.de] has joined #wesnoth-dev
20160724 20:08:52< loonycyborg> would be really nice, I don't trust myself to do a thorough test.
20160724 20:09:37< celticminstrel> I'm probably not a good choice for a thorough test either...
20160724 20:09:56< celticminstrel> Unless I had a bulleted list of things to try or something.
20160724 20:10:25< celticminstrel> But I should be able to do some basic sanity tests...
20160724 20:16:06-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 250 seconds]
20160724 20:26:39< bumbadadabum> an idea I had: Would there be people interested in sortof a wesnoth UMC dev revival on git
20160724 20:26:53< bumbadadabum> like a github organization for hosting wesnoth UMC
20160724 20:27:35< bumbadadabum> to have a sort of "development community" again
20160724 20:28:03< bumbadadabum> and people could help others with fixing bugs, running tools etc
20160724 20:33:51-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds]
20160724 20:43:34< irker339> wesnoth: loonycyborg wesnoth:master 8ef3e27ece33 / po/wesnoth-manpages/it.po: Fix unknown <> sequence error https://github.com/wesnoth/wesnoth/commit/8ef3e27ece3334a85fa143c620feaf064adf0781
20160724 20:43:36< irker339> wesnoth: loonycyborg wesnoth:master b63d6f7e2ace / / (1419 files in 27 dirs): pot-update and regenerate doc files https://github.com/wesnoth/wesnoth/commit/b63d6f7e2ace27fdad457b60ebe0d24f3c1ee6ee
20160724 20:44:17< loonycyborg> Ivanovic: shouldn't your own testing detect error in https://github.com/wesnoth/wesnoth/commit/8ef3e27ece3334a85fa143c620feaf064adf0781
20160724 20:44:20< loonycyborg> ?
20160724 20:51:52-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160724 21:02:28-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160724 21:06:12-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160724 21:08:48-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 258 seconds]
20160724 21:08:48-!- wedge010 is now known as wedge009
20160724 21:14:01-!- un214 [~un214@104.220.56.173] has joined #wesnoth-dev
20160724 21:20:25-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160724 21:21:47-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160724 21:44:23< Ivanovic> loonycyborg: sorry, but the manpages are only recreated at "release time"
20160724 21:44:28< Ivanovic> so no, my testing does not cover that part
20160724 21:44:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160724 21:47:46< Aginor> celmin: I don't think anyone's done a basic sanity check
20160724 21:54:20< loonycyborg> Aginor: you could do some yourself too, there is no such thing as too much testing
20160724 21:57:47-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 2080 Yes, 506 No, 33 AML | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160724 21:58:21< vultraz> #49 :D
20160724 21:58:24< vultraz> We broke the top 50!
20160724 21:58:27< Aginor> loonycyborg: I have been doing bits and bobs of it, but nothing structured
20160724 22:00:03< loonycyborg> we already got automated structured tests as part of travis
20160724 22:00:32< Aginor> loonycyborg: they leave a lot uncovered
20160724 22:00:59< loonycyborg> and the only problem that there always be some bugs that will slip through any structure
20160724 22:01:06< loonycyborg> so manual tests are always needed
20160724 22:03:17< loonycyborg> only actual devs can keep track of recent changes and based on that figure out what things could break\
20160724 22:04:15< celmin> Well, when I say "basic sanity tests" I mean things like "try connecting to the server, start a game and attack a unit, open preferences", etc
20160724 22:04:19< loonycyborg> uff I changed keyboard recently and still hitting \ accidentally due to habit, cause on old keyboard enter key had a different shape :P
20160724 22:04:34< loonycyborg> celmin: it's part of ReleasingWesnoth checklist
20160724 22:04:41< celmin> Yeah.
20160724 22:04:46< loonycyborg> so I'll be doing that
20160724 22:04:53< celmin> But despite that a major bug snuck in last time.
20160724 22:05:02< celmin> Okay.
20160724 22:06:38-!- mjs-de [~mjs-de@x4db6b606.dyn.telefonica.de] has quit [Remote host closed the connection]
20160724 22:07:02< Aginor> celmin: finish a scenaroip ;)
20160724 22:07:08< celmin> ???
20160724 22:07:21< Aginor> celmin: finish a scenario ;)
20160724 22:07:30< celmin> My confusion was not at your typo
20160724 22:07:37< Aginor> so we test transitions between scenarios too
20160724 22:08:22< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 7989384acba9 / src/addon/validation.cpp: Attempt to fix travis https://github.com/wesnoth/wesnoth/commit/7989384acba9fa172e61a781f429d30485a5f581
20160724 22:09:04< loonycyborg> celmin: the fun part about that bug was that release checklist says to use droid command
20160724 22:09:13< loonycyborg> which doesn't involve attack dialogs
20160724 22:11:26< celmin> Ah, I see.
20160724 22:11:37< celmin> (That was meant at Aginor)
20160724 22:12:05< celmin> Gah, vultraz went and made another commit before I could push. Now I have to go and do a full rebuild or something.
20160724 22:12:14< vultraz> wat
20160724 22:12:20< vultraz> I changed one cpp file :|
20160724 22:12:39< celmin> Because I need to rebase, which means all those files are marked as touched too.
20160724 22:12:40-!- gfgtdf [~chatzilla@x4e36a7ec.dyn.telefonica.de] has joined #wesnoth-dev
20160724 22:12:56< celmin> But it's more my fault than yours (I could've pushed an hour ago and didn't).
20160724 22:13:18< celmin> Unrelatedly, I got my sister to vote on Greenlight finally.
20160724 22:13:38< vultraz> :D
20160724 22:13:45< celmin> Oh, I forgot, I hadn't yet committed this and still had one issue to resolve… whoops...
20160724 22:14:06< vultraz> well there you go
20160724 22:14:08< vultraz> no rebase
20160724 22:14:15< celmin> No, still need to rebase.
20160724 22:14:26< celmin> Because it's just the last of several commits.
20160724 22:14:33< celmin> (Three if I recall correctly.)
20160724 22:14:56< celmin> BTW, if you want to rebase and squash stuff, now would be a good time, before I add my own commits.
20160724 22:15:23< celmin> Not that there's anything preventing you from doing it after I add my commits.
20160724 22:15:32< vultraz> I was waiting for your commit to squash with the formula stuff
20160724 22:15:40-!- un214 [~un214@104.220.56.173] has quit [Remote host closed the connection]
20160724 22:15:42< celmin> Eh...
20160724 22:16:12< vultraz> I could do it now
20160724 22:16:18< celmin> I'd rather be the one to squash that so that both our names are attached to the commit.
20160724 22:16:40< vultraz> ok, then gimme some time to split that formula stuff from the big commit
20160724 22:16:45< celmin> Okay.
20160724 22:16:47< vultraz> then I need to squash a bunch of stuff
20160724 22:17:05< celmin> There were four formula lines to split out.
20160724 22:17:25< vultraz> [03:46:39]	celticminstrel	So anyway, there are four lines in the diff that should be moved to the formula commit. Two in units/formula_manager.cpp, one in units/formula_manager.hpp, and one in units/filter.cpp.
20160724 22:17:34< celmin> Yup yup
20160724 22:19:56< vultraz> lastis the std::shared_ptr<unit_callable> secondary(new unit_callable(*u2)); line?
20160724 22:20:07< vultraz> which used to be an intrusive_ptr?
20160724 22:20:33< celmin> Is that in filter.cpp? That's probably the one.
20160724 22:20:40< vultraz> yes
20160724 22:20:51< celmin> Yes, it used to be an intrusive_ptr.
20160724 22:21:35-!- travis-ci [~travis-ci@ec2-50-19-60-2.compute-1.amazonaws.com] has joined #wesnoth-dev
20160724 22:21:36< travis-ci> wesnoth/wesnoth#9930 (boost_trimming - 7989384 : Charles Dang): The build is still failing.
20160724 22:21:36< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147062511
20160724 22:21:36-!- travis-ci [~travis-ci@ec2-50-19-60-2.compute-1.amazonaws.com] has left #wesnoth-dev []
20160724 22:22:17< celmin> Looks like another missing <algorithm>
20160724 22:23:49< vultraz> ill include a fix
20160724 22:28:58< vultraz> ok, squashed everything into the main commits
20160724 22:29:33< vultraz> celmin: can we merge 711 while I'm rebasing?
20160724 22:31:06< celmin> No, sorry.
20160724 22:31:11< vultraz> ok
20160724 22:31:15< vultraz> will force push what I have
20160724 22:31:18< celmin> Just saw it now, and commented on it.
20160724 22:31:44< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 05092ba2f695 / src/ (192 files in 37 dirs): Refactor most boost pointer related stuff to use their stdlib counterparts https://github.com/wesnoth/wesnoth/commit/05092ba2f6952ca9e06b1bf4420353894302f4ac
20160724 22:31:47< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 563947e1b344 / src/gui/ (30 files in 4 dirs): Refactored GUI2's uses of boost::intrusive_ptr https://github.com/wesnoth/wesnoth/commit/563947e1b344dd3a44850feab113136635966cb0
20160724 22:31:50< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 04c1af1d9527 / / (17 files in 7 dirs): Refactored formula's use of boost::intrusive_ptr https://github.com/wesnoth/wesnoth/commit/04c1af1d9527b07e8447f0e0c74013c2f0f1b343
20160724 22:32:01< vultraz> ^
20160724 22:35:30< vultraz> I squashed the removal of the refcounting header into the formula commit
20160724 22:40:39< vultraz> maybe should have left that as a separate commit
20160724 22:40:51< celmin> Doesn't really matter that much.
20160724 22:41:09< celmin> Actually, I was including my removal of it from XCode in the same commit as the rest of my alterations.
20160724 22:41:16< vultraz> either way, everything should be in its proper commit now
20160724 22:41:19< vultraz> I await your changes
20160724 22:45:17< vultraz> Which reminds me, I should probably figure out how to use dynamic_pointer_cast in the GUI2 commit again
20160724 22:45:32< vultraz> apparently, iceiceice said static casting is dangerous in GUi2?
20160724 22:46:09< celmin> Wait, what?
20160724 22:46:11< vultraz> "In general, replacing dynamic cast with static cast in GUI2 code can cause some really horrible memory corruption problems that will be very hard to detect and solve"
20160724 22:46:24< celmin> Did you replace dynamic casts with static casts?
20160724 22:46:28< vultraz> yes
20160724 22:46:31< celmin> Why>
20160724 22:46:33< vultraz> dynamic wouldn't build
20160724 22:46:48< celmin> Never replace dynamic with static unless you understand exactly what you're doing.
20160724 22:46:58< celmin> Which commit is it?
20160724 22:47:01< vultraz> so I used static_pointer_cast just because it built
20160724 22:47:04< celmin> Oh, the GUI2 one.
20160724 22:47:19< celmin> I'll look over it then.
20160724 22:48:05< celmin> BTW, the formula commit was after the GUI2 commit, right?
20160724 22:49:03< vultraz> Yes
20160724 22:50:47< celmin> vultraz: Okay, so, what kind of errors did dynamic_pointer_cast give?
20160724 22:51:47< vultraz> ill have to get one again
20160724 22:52:09< celmin> gui/widgets/horizontal_scrollbar.cpp:39 is the first one.
20160724 22:52:45< vultraz> first I need to rebuild after my rebasing
20160724 22:53:23< gfgtdf> vultraz: is there a reason wh you are doing this std stuff now?
20160724 22:56:48< vultraz> gfgtdf: not any reason, we just ended up working on it
20160724 22:57:02< vultraz> i think because someone has build problems ..
20160724 22:57:12< vultraz> ancestral
20160724 22:57:33< celmin> Oh right, ancestral did have build problems which were related to boost::bind. Or maybe it was std::bind. One of those.
20160724 22:59:46< celmin> Actually it was related to boost::arg, so I'm not sure these changes would fix his problems, but… well, whatever.
20160724 22:59:56< vultraz> Either way, it's good cleanup
20160724 23:00:18< celmin> Then again, if we can eliminate the use of that header which is implicitly including Boost.Bind, then that would definitely fix his problems.
20160724 23:00:32< celmin> On the other hand, I suspect that header is something essential rather than one of the ones that have std equivalents.
20160724 23:00:34< vultraz> Dunno which header it is, though
20160724 23:00:35-!- travis-ci [~travis-ci@ec2-50-19-60-2.compute-1.amazonaws.com] has joined #wesnoth-dev
20160724 23:00:36< travis-ci> wesnoth/wesnoth#9931 (boost_trimming - 04c1af1 : Charles Dang): The build is still failing.
20160724 23:00:36< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147065390
20160724 23:00:36-!- travis-ci [~travis-ci@ec2-50-19-60-2.compute-1.amazonaws.com] has left #wesnoth-dev []
20160724 23:01:58< celmin> I think Travis would be a bit more helpful if it didn't stop as soon as any single file produces an error but rather continued until it has attempted to compile every file.
20160724 23:02:37< celmin> I've set up XCode to do this (I don't remember if it's a project setting or a global setting).
20160724 23:03:22< vultraz> it says an std::string has an incomplete type
20160724 23:03:24< vultraz> wat
20160724 23:03:46< celmin> That means <string> needs to be included, but which file is it? I added two <string> includes already, so that might fix it.
20160724 23:03:59< gfgtdf> celmin: i fully agree, this is actuall why most of the build compile without -werror so that it dosnt stop on the first warning. unfortunaleley its not that easy for errors
20160724 23:04:03< vultraz> hotkey/hotkey_item.hpp
20160724 23:04:56< celmin> Yeah, got that one.
20160724 23:05:20-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 258 seconds]
20160724 23:05:23< vultraz> good, good
20160724 23:17:33< celmin> vultraz: Build finished yet?
20160724 23:17:42< vultraz> just now
20160724 23:18:21< vultraz> C:\TDM-GCC-32\lib\gcc\mingw32\5.1.0\include\c++\bits\shared_ptr.h|458|error: cannot dynamic_cast '(& __r)->std::shared_ptr<const gui2::tresolution_definition_>::<anonymous>.std::__shared_ptr<_Tp, _Lp>::get<const gui2::tresolution_definition_, (__gnu_cxx::_Lock_policy)2u>()' (of type 'const struct gui2::tresolution_definition_*') to type 'const struct gui2::thorizontal_scrollbar_definition::tresolu
20160724 23:18:22< vultraz> tion*' (source type is not polymorphic)|
20160724 23:18:22< celmin> So about gui/widgets/horizontal_scrollbar.cpp:39,,,
20160724 23:18:25< celmin> Oh.
20160724 23:18:28< celmin> Hmm.
20160724 23:20:00< vultraz> I don't know the implementation detail of boost::dynamic_pointer_cast
20160724 23:20:56< celmin> Unrelatedly, I dislike how line 39 is randomly split in two.
20160724 23:21:10< vultraz> as do I
20160724 23:21:26< vultraz> it was part of mordante's weird IT MUST BE NO MORE THAN 80 CHARS EVER thing
20160724 23:21:49< celmin> Yeah, uhh… that's kinda dumb these days. Nearly everyone can display far more than 80 chars.
20160724 23:22:01< vultraz> anyway, do you think it's safe to stick with static_pointer_cast?
20160724 23:22:19< celmin> I'm trying to understand what's even happening here. Why is it passing config() to the cast… :|
20160724 23:22:46< celmin> And how does it get gui2::tresolution_definition_ from that...
20160724 23:22:51< vultraz> it's casting it to a tesolution type of its own
20160724 23:23:22< vultraz> gui2::tresolution_definition_ is the expansion of a typdef
20160724 23:23:27< celmin> Can you find the definition of tresolution_definition_?
20160724 23:23:32< celmin> Wait what?
20160724 23:24:01< vultraz> er
20160724 23:24:03< vultraz> wait
20160724 23:24:05< vultraz> that's something else
20160724 23:24:14< vultraz> it's a struct
20160724 23:24:21< celmin> Does it have any virtual methods?
20160724 23:24:25< vultraz> typedef std::shared_ptr<tresolution_definition_> tresolution_definition_ptr; is what I was thinking of
20160724 23:24:32< vultraz> celmin: no
20160724 23:24:39< celmin> So the error message is accurate in that respect.
20160724 23:24:41< celmin> Okay..
20160724 23:24:57< celmin> Does it have a constructor that takes a config?
20160724 23:25:07< vultraz> yes
20160724 23:25:10< celmin> Hmm.
20160724 23:25:44< celmin> I think the line should probably use make_shared, actually.
20160724 23:26:01< celmin> As far as I can see, the goal is not to cast but just to get a new pointer.
20160724 23:26:17< celmin> Given that the tresolution is being constructed directly into the cast.
20160724 23:26:41< celmin> But… I might be misunderstanding something...
20160724 23:26:58< celmin> Because it seems to be expecting that pointer to actually point to something.
20160724 23:27:01< vultraz> make_shared doesn't work
20160724 23:27:04< celmin> But how is that even possible...
20160724 23:27:27-!- Duthlet [~Duthlet@dslb-188-104-247-201.188.104.pools.vodafone-ip.de] has quit [Ping timeout: 244 seconds]
20160724 23:27:51< vultraz> C:\TDM-GCC-32\lib\gcc\mingw32\5.1.0\include\c++\ext\new_allocator.h|120|error: no matching function for call to 'gui2::thorizontal_scrollbar_definition::tresolution::tresolution(std::shared_ptr<const gui2::tresolution_definition_>)'|
20160724 23:28:15< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\gui\widgets\horizontal_scrollbar.cpp|175|note: candidate: gui2::thorizontal_scrollbar_definition::tresolution::tresolution(const config&)|
20160724 23:28:27< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\gui\widgets\horizontal_scrollbar.cpp|175|note:   no known conversion for argument 1 from 'std::shared_ptr<const gui2::tresolution_definition_>' to 'const config&'|
20160724 23:28:35< vultraz> that's why
20160724 23:28:44< celmin> Oh, wait a second. Could it be that thorizontal_scrollbar has a function called config?
20160724 23:29:23< vultraz> I think it inherits one
20160724 23:30:21< celmin> Okay, that could resolve my confusion. I assumed that config() was constructing an empty config object, but if it's instead calling a member function that returns a tresolution_definition_, then the error makes more sense.
20160724 23:30:39< celmin> Given that, it actually feels that static_pointer_cast is the right choice in this case.
20160724 23:30:50< vultraz> alright, good
20160724 23:31:08< vultraz> so we can leave the gui2 commit alone?
20160724 23:31:21< celmin> I'm pretty sure static_pointer_cast does enforce that the types are related by inheritance.
20160724 23:32:04< vultraz> "The function can only cast types for which the following expression would be valid: static_cast<T*>(sp.get())"
20160724 23:32:21< celmin> It looks like those were incorrectly using dynamic_pointer_cast originally.
20160724 23:32:33< celmin> I guess Boost's version is more lenient about that.
20160724 23:32:59< celmin> (You'd need a reinterpret_cast if there was no inheritance relationship.)
20160724 23:33:16< vultraz> ok, so we're safe :)
20160724 23:33:29< celmin> Well, there's the other possibility though.
20160724 23:33:35< vultraz> that being?
20160724 23:33:52< celmin> The possibility that tresolution_definition_ is supposed to have virtual functions.
20160724 23:34:05< celmin> Or something.
20160724 23:34:25< vultraz> if it does we'll deal with that when the time comes
20160724 23:34:47< celmin> For example, does it have a minimum_positioner_length_ member?
20160724 23:34:50< vultraz> are your commits ready?
20160724 23:34:54< celmin> Yeah.
20160724 23:35:02< vultraz> it does not
20160724 23:35:09< celmin> Hmm.
20160724 23:35:32< celmin> What file is it in?
20160724 23:35:39< celmin> And line number would help too.
20160724 23:35:59< vultraz> gui/core/widget_definition.hpp:41
20160724 23:37:34< celmin> If you added one line to it, all those dynamic casts would become valid, but the question is, which is the right fix?
20160724 23:38:20< vultraz> I think let's leave the definition as-in.
20160724 23:38:33< celmin> I don't think this is something that can be decided that easily.
20160724 23:39:18< vultraz> well, could you at least push your commits
20160724 23:39:27< celmin> Yeah, getting there. Have rebase conflicts.
20160724 23:39:46< celmin> Hmm, the static_cast might actually be perfectly safe - as long as you can guarantee that a thorizontal_scrollbar never uses any other type of tresolution.
20160724 23:40:00< celmin> Which seems logical to me.
20160724 23:40:13< celmin> BTW, besides those ones you added, are there any other uses of static_pointer_cast?
20160724 23:40:24< vultraz> in the code at all?
20160724 23:40:29< celmin> Yeah.
20160724 23:40:54< celmin> Or, at least in the GUI2 area.
20160724 23:41:12< vultraz> it's used in the whiteboard
20160724 23:41:15< vultraz> and the whiteboard test
20160724 23:41:22< vultraz> otherwise gui2 is the only place
20160724 23:41:29< vultraz> and I think I added all the gui2 ones
20160724 23:41:45< celmin> Okay, in that case, let's leave it like this for the now and scrutinize it more closely later. Preferably before merging this though.
20160724 23:42:14< vultraz> ok
20160724 23:44:44< celmin> Okay, just to be clear, your squashed commits cover "Refactor most boost pointer related stuff", "Refactored GUI2's uses of intrusive_ptr", "Refactor formula's use of intrusive_ptr", the fixup, "remove custom ref counting header", and "const-ified eligible unique_ptrs", right?
20160724 23:45:05< celmin> Apparently the rebase is not smart enough to detect that they're the same, so I'm going to remove them manually with --interactive
20160724 23:45:40< celmin> But want to make sure I don't accidentally remove something that I shouldn't.
20160724 23:46:47< vultraz> not exactly, since I also split commits, merged fixup commits..
20160724 23:46:59< vultraz> but their content, yes
20160724 23:47:04< celmin> Yeah, their content was the point.
20160724 23:47:34< vultraz> also the attempt to fix travis one
20160724 23:47:52< celmin> Right.
20160724 23:48:05< celmin> I didn't have that one in the first place though, so that wasn't a problem.
20160724 23:56:01< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 1b50d42639dd / / (18 files in 8 dirs): Refactored formula's use of boost::intrusive_ptr https://github.com/wesnoth/wesnoth/commit/1b50d42639dd2d2fbd35a15e86c09375c4aef131
20160724 23:56:04< irker339> wesnoth: Celtic Minstrel wesnoth:boost_trimming f16a3d03ee9b / src/ (game_events/wmi_container.hpp hotkey/hotkey_item.hpp): Fix some missing <string> https://github.com/wesnoth/wesnoth/commit/f16a3d03ee9b59f1bf9cf19f593166e0755e26a4
20160724 23:56:06< irker339> wesnoth: Celtic Minstrel wesnoth:boost_trimming f0888ee536ca / src/server/server.cpp: Eliminate boost::bind in wesnothd https://github.com/wesnoth/wesnoth/commit/f0888ee536ca10ba1154f85ea628803190e5c021
20160724 23:57:26-!- u1611 [57ac5b99@gateway/web/freenode/ip.87.172.91.153] has joined #wesnoth-dev
20160724 23:58:39< celmin> There's one more commit, but that conflicts with 711 so I want to discuss that out first.
--- Log closed Mon Jul 25 00:00:40 2016