--- Log opened Mon Jul 25 00:00:40 2016
20160725 00:02:30< vultraz> ah, nice, nice
20160725 00:02:40< vultraz> you removed the rest of the formula refcount stuff
20160725 00:02:42< vultraz> thanks
20160725 00:02:48< celmin> Yeah.
20160725 00:03:26< celmin> It was actually still maintaining a refcount that was never used. :P
20160725 00:04:18< vultraz> blah, I dunno how to get a branch up-to-date after someone forcepushes
20160725 00:04:26< celmin> It's surprisingly easy.
20160725 00:04:30< celmin> git fetch
20160725 00:04:35< celmin> git reset FETCH_HEAD
20160725 00:04:38< celmin> git reset --hard
20160725 00:04:43< celmin> Last two can probably be combined.
20160725 00:04:50< celmin> Also, make sure you stash first if applicable.
20160725 00:05:08< celmin> Because reset --hard doesn't fail if you have unstashed changes since its purpose is usually to drop those changes.
20160725 00:05:39< celmin> (Also, that assumes you're already on the relevant branch and also that the upstream has been properly set.)
20160725 00:06:51< vultraz> one of the things that's easier with the command line instead of the GUI
20160725 00:06:53< vultraz> heh
20160725 00:07:42< vultraz> it seems like the formula refactor was quire worthwhile
20160725 00:07:51< celmin> Apart from the fact that git's command-line options are kind of inconsistent.
20160725 00:07:59< celmin> Huh? By what measure do you call it worthwhile>
20160725 00:08:01< celmin> ^?
20160725 00:08:23< vultraz> it cleaned out a lot of unnecessary code
20160725 00:08:51< vultraz> only 3 uses of intrusive_ptr left in the code, FYI
20160725 00:08:59< celmin> Might as well just leave those ones.
20160725 00:09:24< vultraz> would  be nice to refactor the unit_ptr but that's a big project
20160725 00:09:37< celmin> And probably not worth it.
20160725 00:10:34< vultraz> and I really can't figure out what the one in units/map.hpp:134 is doing
20160725 00:11:46< celmin> Imagine that value_type is unit.
20160725 00:12:05< celmin> Those typedefs are required for standard library algorithms to work with the unit iterators.
20160725 00:12:10< celmin> Unit map iterators, I guess.
20160725 00:12:21< celmin> This is why I added those typedefs to the variant iterator, incidentally.
20160725 00:12:34< vultraz> why the heck is this needed: typedef int difference_type;
20160725 00:12:48< celmin> I'm not quite sure.
20160725 00:13:29< vultraz> maybe it used to be something else
20160725 00:13:40< celmin> Actually, normally it should be std::ptrdiff_t...
20160725 00:14:06< celmin> Which may or may not actually be the same as int, depending on the platform.
20160725 00:14:17< vultraz> huh
20160725 00:14:35< celmin> I'm not quite sure what the purpose of difference_type is though. The others are more obvious, I think.
20160725 00:14:56< celmin> Oh, there's also size_type I guess.
20160725 00:16:09< vultraz> The only other boost thing that might be std-convertable is boost::tuple
20160725 00:16:11< vultraz> not sure tho
20160725 00:16:20< celmin> Probably is, yeah.
20160725 00:17:05< vultraz> was gonna say boost::optional too but apparently that's c++17 O_O
20160725 00:17:19< celmin> Okay.
20160725 00:18:18< vultraz> oh, there's also boost::is_same
20160725 00:18:28< celmin> Isn't that in <type_traits>?
20160725 00:18:41< celmin> At least, it looks like a type trait.
20160725 00:18:50< vultraz> seems so
20160725 00:18:53< vultraz> why?
20160725 00:19:10< celmin> Type traits can probably be converted to std too, for the most part.
20160725 00:19:20< vultraz> also std::enable_if
20160725 00:20:05< vultraz> is_base_of
20160725 00:20:16< celmin> Yeah, all those are type traits.
20160725 00:20:35< celmin> Anything in <boost/type_traits> is probably applicable. There might be a few exceptions.
20160725 00:20:48< celmin> I think Boost does have a few extra type traits compared to (C++11) std.
20160725 00:21:20< vultraz> I'll start with boost::tuple
20160725 00:21:24< vultraz> then deal with type_traits
20160725 00:21:25-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20160725 00:21:31< vultraz> unless you want to deal with type_traits?
20160725 00:21:50< celmin> I can try working on type traits, I suppose.
20160725 00:22:29< vultraz> they're not that extensive
20160725 00:24:16< celmin> I see eight files including them.
20160725 00:24:35< celmin> But one of them is config.hpp
20160725 00:25:57< celmin> Wait, sorry, not eight files.
20160725 00:26:00-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has quit [Quit: Leaving]
20160725 00:26:02< celmin> Six files.
20160725 00:26:27< celmin> config.hpp separately includes three different traits. The standard library doesn't allow this though.
20160725 00:26:40< vultraz> what do you mean?
20160725 00:26:58-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 00:26:59< travis-ci> wesnoth/wesnoth#9932 (boost_trimming - f0888ee : Celtic Minstrel): The build is still failing.
20160725 00:26:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147073696
20160725 00:26:59-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 00:27:48-!- u1611 [57ac5b99@gateway/web/freenode/ip.87.172.91.153] has quit [Quit: Page closed]
20160725 00:27:49< celmin> The standard library doesn't have any sort of one-class-per-file policy.
20160725 00:28:29< celmin> Boost does.
20160725 00:29:04< celmin> So, each type trait is in its own file, and thus you can include just the ones you need and nothing more.
20160725 00:29:35< vultraz> ah
20160725 00:30:01< celmin> Or you can include all of them in one line, because Boost provides collective headers too.
20160725 00:31:57< vultraz> hmm
20160725 00:32:06< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\actions\create.cpp|648|error: could not convert 'true' from 'bool' to 'actions::place_recruit_result {aka std::tuple<bool, int, bool>}'|
20160725 00:32:15< vultraz> guess boost::tuple was more lenient about this
20160725 00:32:24< celmin> Hmm.
20160725 00:32:34< celmin> What is an actions::place_recruit_result.
20160725 00:33:17< vultraz> typedef std::tuple<bool /*event modified*/, int /*previous village owner side*/, bool /*capture bonus time*/> place_recruit_result;
20160725 00:33:26< celmin> Ah.
20160725 00:33:35< celmin> Try enclosing it in braces.
20160725 00:33:40< celmin> {true}
20160725 00:34:18< celmin> If that doesn't work you might need {true, 0, false} – spelling the defaults out in full.
20160725 00:35:20< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\actions\create.cpp|648|error: converting to 'actions::place_recruit_result {aka std::tuple<bool, int, bool>}' from initializer list would use explicit constructor 'constexpr std::tuple< <template-parameter-1-1> >::tuple(_UElements&& ...) [with _UElements = {bool, int, bool}; <template-parameter-2-2> = void; _Elements = {bool, int, bool}]'|
20160725 00:35:22< vultraz> o_O
20160725 00:35:47< celmin> That's with {true}?
20160725 00:35:55< vultraz> no, that didn't work
20160725 00:35:58< vultraz> ah
20160725 00:35:58< celmin> I actually think this case might be better replaced with a struct.
20160725 00:36:04< vultraz> I think this is the problem
20160725 00:36:06< vultraz> "Until C++17, a function could not return a tuple using list-initialization:"
20160725 00:36:15< celmin> Since there are comments giving "names" to each element.
20160725 00:37:31< celmin> Tuples are kind of like anonymous structs anyway.
20160725 00:37:46< vultraz> hm
20160725 00:37:51< vultraz> make_tuple works
20160725 00:37:56< celmin> Ah, yes.
20160725 00:38:22< vultraz> I might refactor it as a struct later
20160725 00:38:28< vultraz> first to get stuff building
20160725 00:38:42< celmin> Does make_tuple(true) work?
20160725 00:38:47< celmin> Or do you need all three elements?
20160725 00:39:19< vultraz> seems to work
20160725 00:39:39< vultraz> hmmm
20160725 00:39:42< vultraz> what is going on heeeere
20160725 00:39:46< vultraz>  // this class is needed since boost has some templated operators>> declared internally for tuples and we don't want them to interfere. Existence of such operator>> apparently causes program_options to cause the custom class somehow specially... well, the std::tuple default operator>>  format doesn't suit our needs anyway.
20160725 00:39:48< vultraz> class two_strings : public std::tuple<std::string,std::string> {};
20160725 00:39:59< vultraz> unless I'm dumb, isn't that a pair
20160725 00:40:09< celmin> Hmm.
20160725 00:40:18< celmin> File and line?
20160725 00:40:32< vultraz> commandline_options.cpp:37
20160725 00:41:38< vultraz> I don't think that's even used..
20160725 00:41:53< celmin> Oh? If it's not used, go ahead and remove it...
20160725 00:42:06< celmin> But you're also right that that's the same as a pair.
20160725 00:42:38< vultraz> well two_strings is in the static validate() function but I can't find a usecase for that in the file
20160725 00:42:55< celmin> So validate() is not used?
20160725 00:43:10< vultraz> doesn't appear to be
20160725 00:43:16< celmin> Yeah, it doesn't.
20160725 00:43:28< celmin> I guess you could delete that. Probably as a separate commit from the tuples.
20160725 00:44:24< vultraz> what is with this file using tuples and not pairs!
20160725 00:44:37< celmin> I dunno, there might be a good reason.
20160725 00:44:43< vultraz> did std::pair not exist in 2003 or something?
20160725 00:44:51< celmin> Since according to that comment, they're treated specially by Boost.ProgramOptions.
20160725 00:44:59< celmin> Maybe pair does not receive that special treatment.
20160725 00:45:25< vultraz> I'll try converting them to pairs and see what happens
20160725 00:46:15< celmin> Uhh… by "see what happens" I hope you mean "passing appropriate commandline options to see if they still work".
20160725 00:47:12< vultraz> I would do that, yes
20160725 00:53:34< gfgtdf> vultraz: why would you use pair rather than tuple?
20160725 00:53:46< vultraz> gfgtdf: if the tuple only has 2 
20160725 00:53:53< celmin> There's not really any reason to.
20160725 00:55:42< gfgtdf> vultraz: well, tuple has some advantages, for example it provides relation operators, also its easier tpo add a third member if you want to. OIn the other had i see no advantages that pair has over tuple
20160725 00:56:07< vultraz> hmm the two_strings thing is actually used in one case..
20160725 00:58:00< celmin> Two cases, even.
20160725 00:58:26< celmin> I guess you'd better leave it as is then.
20160725 00:58:41< vultraz> I can still remove validate()
20160725 00:58:47< celmin> I bet you can't.
20160725 00:59:02< celmin> I imagine it's called internally from something in Boost.ProgramOptions.
20160725 01:04:29< vultraz> sadly, you appear to be right
20160725 01:17:05-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160725 01:20:00-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 2159 Yes, 534 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
20160725 01:20:05< vultraz> #46
20160725 01:22:42-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160725 01:27:01-!- gfgtdf_ [~chatzilla@x4e36ae7a.dyn.telefonica.de] has joined #wesnoth-dev
20160725 01:28:47< bumbadadabum> d-did anyone have opinions about the UMC-dev revival?
20160725 01:29:22-!- gfgtdf [~chatzilla@x4e36a7ec.dyn.telefonica.de] has quit [Ping timeout: 265 seconds]
20160725 01:29:26-!- gfgtdf_ is now known as gfgtdf
20160725 01:30:53< vultraz> bumbadadabum: don't think it's worth it
20160725 01:31:24< bumbadadabum> idk I'd like to have some sort of "group" feeling of UMC developers again
20160725 01:32:03< bumbadadabum> and on git you can give everyone their own repo still
20160725 01:32:16< bumbadadabum> but have everything in one namespace so you can still have that cooperative feeling
20160725 01:32:50< bumbadadabum> just wanna help the community and stuff
20160725 01:33:05< bumbadadabum> should I ask on the forums maybe if people would like tha
20160725 01:33:08< bumbadadabum> *that
20160725 01:33:21< celmin> bumbadadabum: I was going to say I'm not really interested in the proposal.
20160725 01:33:47< celmin> You can feel free to ask on the forums if you want though, I guess.
20160725 01:34:04< bumbadadabum> idk if there's no motivation for it here I doubt there'd be on the forums
20160725 01:34:30< celmin> How many UMC devs actually come here though.
20160725 01:34:55< celmin> I can think of four or five off the top of my head.
20160725 01:35:07< bumbadadabum> yeah
20160725 01:35:10< bumbadadabum> I guess I could ask
20160725 01:35:20< celmin> There might be more that I'm not aware of, admittedly.
20160725 01:36:18< vultraz> huh. what is boost::tuples::ignore
20160725 01:36:31< celmin> Good question. What is it?
20160725 01:36:43< vultraz> oh, it's a placeholder
20160725 01:36:56< vultraz> I guess I need std::tuple::ignore (no 's')
20160725 01:37:24< celmin> Huh? Placeholder for what?
20160725 01:37:34< celmin> Oh, could it be for std::tie?
20160725 01:37:55< vultraz> yes
20160725 01:38:02< vultraz> looks like it's just std::ignore
20160725 01:38:21< celmin> So I guess using that means that element of the tuple does not get assigned anywhere. That's useful to know.
20160725 01:42:35< vultraz> tfw you make wesnoth crash on startup
20160725 01:43:00< celmin> ?
20160725 01:43:09< celmin> I don't remember what tfw is.
20160725 01:43:21< shadowm> That feeling when.
20160725 01:43:26< celmin> Ah.
20160725 01:45:06< vultraz> let's see where I went wrong..
20160725 01:45:19< vultraz> uh..
20160725 01:45:21< vultraz> huh
20160725 01:45:25< vultraz> it's a crash in variant
20160725 01:45:28< vultraz> maybe it's not me?
20160725 01:45:29< celmin> Oh my.
20160725 01:45:34< celmin> Maybe not.
20160725 01:45:40< celmin> Formula variant?
20160725 01:46:08< vultraz> #0 0x66a197	variant::variant(std::vector<variant, std::allocator<variant> >*) () (??:??)
20160725 01:46:09< vultraz> #1 0x15ce640	?? () (??:??)
20160725 01:46:11< vultraz> #2 0xf26e4c	game_logic::formula_expression::evaluate(game_logic::formula_callable const&, game_logic::formula_debugger*) const () (??:??)
20160725 01:46:12< vultraz> #3 0x633edd	game_logic::formula::execute(game_logic::formula_callable const&, game_logic::formula_debugger*) const () (??:??)
20160725 01:46:14< vultraz> #4 0x6342ed	game_logic::formula::execute(game_logic::formula_debugger*) const () (??:??)
20160725 01:46:15< vultraz> #5 0x1382ba0	std::__ioinit () (??:??)
20160725 01:46:17< vultraz> #6 ??	?? () (??:??)
20160725 01:46:28< celmin> BTW, what I described for updating after a force-push applies if you have no commits of your own. Don't do it if you've made further commits; in that case you should probably git pull --rebase
20160725 01:47:09-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160725 01:47:20< celmin> That stack trace doesn't feel useful, but I'm goign to see if I can get the crash myself.
20160725 01:47:20< vultraz> noted
20160725 01:47:33< vultraz> for me you just need to start wesnoth
20160725 01:48:12< celmin> Probably because GUI2 uses formulas.
20160725 01:49:48< vultraz> Should I hold off on pushing my tuple change?
20160725 01:51:14< celmin> Yeah, if I can fix it, I'll rebase it into the formula commit and force-push again.
20160725 01:53:51-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 264 seconds]
20160725 01:55:40-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160725 02:00:12-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160725 02:05:43-!- Bonobo [~Bonobo@2001:44b8:254:3200:21e4:6b3b:3dc2:9205] has joined #wesnoth-dev
20160725 02:06:30< celmin> …oh, I almost forgot! I have to update the changelog.
20160725 02:06:44< vultraz> on master?
20160725 02:06:47< celmin> Yeah.
20160725 02:06:56< celmin> I think gfgtdf might need to as well.
20160725 02:16:59-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160725 02:20:21< celmin> …oh. Huh. Looks like I actually have a changelog entry for [role] already.
20160725 02:20:30< celmin> Okay, so I don't need to update the changelog then.
20160725 02:21:08< celmin> Maybe you should check if you have anything to add to the changelog, vultraz.
20160725 02:21:16< vultraz> I don't
20160725 02:21:20< celmin> You sure?
20160725 02:21:31< ancestral> I take it I need to git pull now?
20160725 02:21:39< celmin> Uh. Do you?
20160725 02:21:55< ancestral> Did you guys push commits in the last 24 hours?
20160725 02:22:17< celmin> Well, there are a few. Not directly relevant to you, but I guess it's best to be up-to-date.
20160725 02:22:46< ancestral> Do we likely still have an issue with the BOOST_STATIC_ASSERT?
20160725 02:22:57< celmin> Yeah, nothing has been pushed to address that.
20160725 02:23:14< celmin> There's a branch which is removing uses of boost::bind, though I'm not sure whether that'll help.
20160725 02:23:19< ancestral> Is that a blocker, or should I just comment the boost library for now
20160725 02:24:06< gfgtdf> ancestral: why shodul we have an issue with boost statis assert ?
20160725 02:24:15< celmin> I'm really not sure if commenting that out is safe. If it only affects Mac, then I guess you could do it...
20160725 02:24:40< celmin> gfgtdf: It's used in boost::arg, ie the Boost.Bind placeholders.
20160725 02:24:52< celmin> BTW gfgtdf, do you remember which Boost headers were including Boost.Bind?
20160725 02:24:56< ancestral> That is causing problems
20160725 02:25:06< celmin> Was it something important like asio or filesystem?
20160725 02:25:17< gfgtdf> celmin: no i don'T i thinkwe shoudl assume that any boost header might include it
20160725 02:25:29< gfgtdf> celmin: alos this might differ in boost versions
20160725 02:25:32< celmin> Yeah okay.
20160725 02:25:35< ancestral> And I’m not the only one IIRC? Wasn’t Jyrki having trouble too?
20160725 02:25:48< celmin> I don't think he was having that specific issue.
20160725 02:25:49< ancestral> I have 1.60.0
20160725 02:25:54< gfgtdf> ancestral: which boost and clang versions are you using ?
20160725 02:26:44< ancestral> clang 7.3.0
20160725 02:26:53< celmin> Except not really.
20160725 02:27:05< ancestral> 7.1.1 C++ compiler?
20160725 02:27:34< celmin> Does it have a line like "based on LLVM 3.2svn"?
20160725 02:28:00< ancestral> $ clang -v
20160725 02:28:00< ancestral> Apple LLVM version 7.3.0 (clang-703.0.31)
20160725 02:28:08< celmin> Well, that's kinda unfortunate.
20160725 02:28:45< ancestral> In the project file, I see Apple LLVM 7.1 - Language C++
20160725 02:29:26< celmin> Apple annoyingly bases its clang versions on the XCode versions, which is completely different from the versioning system used by normal clang.
20160725 02:30:07< celmin> I guess it's useful to know that you're in 7.3.0 as long as the difference is known.
20160725 02:32:31< celmin> Okay, it's official. My Wesnoth has crashed, so vultraz's trouble is probably my fault.
20160725 02:32:39< vultraz> :D
20160725 02:32:41< celmin> Waiting for the debugger to respond, then I'll try to see what's wrong.
20160725 02:36:29< celmin> Takes forever because of swapping or something. :|
20160725 02:43:22< celmin> Maybe release() is being called explicitly somewhere other than in the destructor...
20160725 02:44:54< celmin> I wonder if variants should be cached so that, for example, there's only one object for "the integer value 3".
20160725 02:45:12< celmin> I don't think there was such a thing in place before, anyway.
20160725 02:45:22-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 02:45:27< celmin> Geh, still in swap hell.
20160725 02:45:29-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 02:46:12< celmin> Even though all I did was set a breakpoint and try running again.
20160725 02:48:45< celmin> Doesn't look like this is the case...
20160725 02:48:57< celmin> The breakpoint only triggered in the destructor.
20160725 02:49:12< celmin> Then the integrity of the variant is broken somehow maybe?
20160725 02:50:31-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 02:50:41-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 02:53:52< celmin> Maybe two variants shared the same internal pointer?
20160725 02:55:54-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 02:56:01-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 02:56:15-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 02:56:21-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 02:58:25< celmin> Pretty sure this has to be a double-free situation, but I dunno how to deal with it...
20160725 02:59:33-!- gfgtdf [~chatzilla@x4e36ae7a.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160725 03:03:28-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 03:03:38-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 03:05:17-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 03:05:24-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 03:06:55-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 03:07:02-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 03:07:22< celmin> Maybe it's not double-free after all. Maybe it's actually freeing an address that was never allocated in the first place.
20160725 03:07:51< vultraz> can't you just add a  != nullptr check?
20160725 03:07:58< celmin> It's not a null pointer.
20160725 03:08:02-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 03:08:14< celmin> Also, I was under the impression that "delete nullptr" is a safe operation.
20160725 03:08:50< celmin> I definitely discovered an issue with the code here. Not sure if it's the cause of the crash.
20160725 03:09:12< celmin> I'll find out once it builds though.
20160725 03:09:26< celmin> (It was a very terrible issue.)
20160725 03:10:32< irker339> wesnoth: Wedge009 wesnoth:master 0672a7dad629 / utils/pofix.py: Grammar correction for Legend of Wesmere. https://github.com/wesnoth/wesnoth/commit/0672a7dad629d2ee2da91b6de4376f124575aabb
20160725 03:10:45< wedge009> Let me know if I've done that incorrectly. ^
20160725 03:11:10< celmin> Isn't "loose" incorrect here?
20160725 03:11:27< celmin> Wait, what even is that file?
20160725 03:11:32< wedge009> No, lose is opposite of win. Loose is opposite of tight.
20160725 03:11:56< wedge009> It's the description for Landar's win conditions, as best as I can tell.
20160725 03:12:03< wedge009> Second-last scenario.
20160725 03:12:08< celmin> No, that's not what I mean.
20160725 03:12:39< celmin> pofix.py
20160725 03:12:53< wedge009> Oh, I was told to use this for spelling corrections rather than editing the cfg file directly, because doing the latter means it gives translators unnecessary work.
20160725 03:13:13< celmin> Eh… okay...
20160725 03:13:24< celmin> If you were told that by a translation person, I assume it's right.
20160725 03:13:31< wedge009> According to the logs, I think it was aquileia who told me.
20160725 03:13:52< celmin> Though it really seems like an annoying thing to me. I mean, okay, editing the cfg file does give translators extra work, but...
20160725 03:14:28< celmin> Looking at the file header, I feel like it's suppose to supplement changes to the actual cfg file rather than replace them...
20160725 03:15:14< celmin> I'm not the right person to ask though.
20160725 03:15:40< wedge009> The logs say Ivanovic and shadowm use it too.
20160725 03:19:02< celmin> BTW, is it my imagination or was reference_counted_object.hpp never in the MSVC projects?
20160725 03:21:52-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 03:22:01< celmin> Like I thought, "pointer being freed was not allocated"...
20160725 03:30:24< celmin> Aha. The copy constructor is using memcpy. That would be the problem.
20160725 03:30:45< irker339> wesnoth: Wedge009 wesnoth:master 76d8111c82df / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Add missing reference_counted_object.hpp to VC project. https://github.com/wesnoth/wesnoth/commit/76d8111c82df6a0c53a762290b1cecdc55328d2f
20160725 03:31:07< celmin> Well okay, I guess that works.
20160725 03:31:37< celmin> I was actually asking because it was removed in a branch, but I guess it's fine this way.
20160725 03:32:50< wedge009> Huh, it's used in gui/widgets/window.cpp, so I (re-)added it. Though VC seems able to pull headers that aren't explicitly in its project if the file is present.
20160725 03:33:18< wedge009> If it shouldn't be there then the #inclusion should be removed too.
20160725 03:33:38< celmin> No, it's being removed in a branch, so in master it's still used.
20160725 03:35:20< wedge009> Oh, right.
20160725 03:35:52< wedge009> It's no worries, if it does end up being purged, I'll kill it in the project files as well.
20160725 03:38:04< celmin> My new copy assignment operator is if(&v != this) {this->~variant(); new(this) variant(v);} >_>
20160725 03:39:48< celmin> I hope callable pointers don't get leaked. They're not deleted on destruction, but that might be intentional?
20160725 03:40:02< celmin> Okay, no longer crashes on startup.
20160725 03:44:39 * celmin pushes for vultraz 
20160725 03:44:45< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 7a8f3ff11045 / / (18 files in 8 dirs): Refactored formula's use of boost::intrusive_ptr https://github.com/wesnoth/wesnoth/commit/7a8f3ff1104501673a5b0096718f50cd438b7516
20160725 03:44:48< irker339> wesnoth: Celtic Minstrel wesnoth:boost_trimming 9d39a06ae266 / src/ (game_events/wmi_container.hpp hotkey/hotkey_item.hpp): Fix some missing <string> https://github.com/wesnoth/wesnoth/commit/9d39a06ae266c61e2da4752960979434ca35b9cf
20160725 03:44:50< irker339> wesnoth: Celtic Minstrel wesnoth:boost_trimming 09153f07bc60 / src/server/server.cpp: Eliminate boost::bind in wesnothd https://github.com/wesnoth/wesnoth/commit/09153f07bc601ec1a54f5ff3f16ce682ad0201ee
20160725 03:51:09-!- travis-ci [~travis-ci@ec2-54-204-202-44.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 03:51:10< travis-ci> wesnoth/wesnoth#9933 (master - 0672a7d : Wedge009): The build has errored.
20160725 03:51:10< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147091890
20160725 03:51:10-!- travis-ci [~travis-ci@ec2-54-204-202-44.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 04:02:43-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20160725 04:06:12< Espreon> Hello, everyone. I tried compiling git head, but this happens no matter what I do: https://pastebin.com/zbhJSszJ
20160725 04:06:33< Espreon> I do indeed have the sdl2 headers installed and the file in question is indeed there (in /usr/include/SDL2), so...
20160725 04:06:46< Espreon> Note that this happens very late in the build process.
20160725 04:07:02< Espreon> I'm doing this with scons, and it says that it detects everything.
20160725 04:08:32< ancestral> Espreon: I got that error
20160725 04:08:44< celmin> But you're not using scons, are you?
20160725 04:08:48< ancestral> I’m not
20160725 04:08:53< ancestral> I was missing the includes for SDL
20160725 04:09:00< celmin> Hmm.
20160725 04:09:01< ancestral> Or the header path to SDL
20160725 04:09:15< ancestral> I think it was that
20160725 04:09:17-!- JyrkiVesterinen [~jyrki@87-100-136-160.bb.dnainternet.fi] has joined #wesnoth-dev
20160725 04:09:18< celmin> Does scons correctly consider /usr/include/SDL2 to be the path for the SDL includes?
20160725 04:09:32< Espreon> Hmmm... let's see.
20160725 04:09:46< celmin> I'm actually a bit surprised that the SDL includes are not prefixed.
20160725 04:10:28< Espreon> When I tried looking at what it had set, I didn't really see anything SDL2-related. I guess I'll try setting this "sdldir" thing to "/usr/include/SDL2" and see what happens.
20160725 04:11:27< celmin> Hi JyrkiVesterinen 
20160725 04:11:46< JyrkiVesterinen> Hello celmin. :)
20160725 04:13:18< ancestral> Hmm, I’m looking at my directory and now I’m not sure if that’s what I did to fix it
20160725 04:14:18< ancestral> Okay, more of less, that’s what happened. I added the Header Search Paths for each SDL library
20160725 04:14:58< ancestral> celmin: BTW I’d like to update the xcodeproject file this week, but you’ll have to tell me if it builds for you before I commit
20160725 04:15:21< celmin> I can try.
20160725 04:15:36< celmin> Provided I know what I'm trying.
20160725 04:16:25< ancestral> Opening another project file and clicking build?
20160725 04:16:37< ancestral> I know, a tall order to ask for ;-)
20160725 04:16:44< celmin> Another? Why another?
20160725 04:16:50< ancestral> My copy modified
20160725 04:16:59< ancestral> Or I could just commit it and see if you complain?
20160725 04:17:20< celmin> So how were you planning to get it to me?
20160725 04:17:58< ancestral> A new git branch, or my personal server, or pastebin or the like (it’s not a binary file is it?)
20160725 04:18:13< celmin> It's a directory of text files.
20160725 04:18:19< ancestral> Wait you’re right, it’s a dir
20160725 04:18:21< celmin> A git branch would probably be easiest.
20160725 04:18:24< ancestral> Right
20160725 04:24:30-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160725 04:24:37-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160725 04:35:07< celmin> I think I get why std::enable_if was changed to take bool instead of typename as the first argument.
20160725 04:35:23< celmin> It means you can combine type traits with the normal boolean operators instead of things like boost::mpl::and_
20160725 04:40:18-!- travis-ci [~travis-ci@ec2-54-204-202-44.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 04:40:19< travis-ci> wesnoth/wesnoth#9935 (boost_trimming - 09153f0 : Celtic Minstrel): The build is still failing.
20160725 04:40:20< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147094839
20160725 04:40:20-!- travis-ci [~travis-ci@ec2-54-204-202-44.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 04:40:51< JyrkiVesterinen> celmin: I quickly looked around if there is a page about dependencies between Boost modules. There is such a page.
20160725 04:40:52< JyrkiVesterinen> http://wesnoth.org/irclogs/2016/07/%23wesnoth-dev.2016-07-24.log
20160725 04:40:58< JyrkiVesterinen> Wrong link.
20160725 04:41:05< JyrkiVesterinen> http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-levels.html
20160725 04:41:18< celmin> Doesn't look official, but may be useful anyway...
20160725 04:43:00< Espreon> And no, that didn't do anything...
20160725 04:43:24< JyrkiVesterinen> These modules depend on Boost.Bind: function, lambda, algorithm, iostreams, phoenix, python, test, tr1, variant, gil, thread, asio, heap, msm, multi_index, statechart, signals2, graph, log, property_map, numeric~odeint.
20160725 04:43:24< Espreon> Though, manually changing the include lines does appear to work... (huzzah...)
20160725 04:44:00< JyrkiVesterinen> We use many of those, in particular Boost.Thread and Boost.Asio.
20160725 04:44:02-!- Kwandulin [~Miranda@p200300760F60627949834AFD203A8320.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160725 04:44:04< celmin> We're using iostreams and asio.
20160725 04:44:08< celmin> Yeah, thread too.
20160725 04:44:23< celmin> I think iostreams is being used for things like compression.
20160725 04:44:24< JyrkiVesterinen> It looks like we can't prevent the Boost.Bind header from being included.
20160725 04:46:25< celmin> Oh, we also use variant.
20160725 04:46:25< celmin> It's integral to the config class
20160725 04:46:25< celmin> That's four libraries depending on Boost.Bind then...
20160725 04:48:14< celmin> Ah, vultraz changed some pointer stuff in the campaign server without testing it. That's why Travis is failing now.
20160725 04:48:58< celmin> Well, it's on the branch, so not high priority.
20160725 05:06:41-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Quit: leaving]
20160725 05:07:24< JyrkiVesterinen> 20160725 02:25:35< ancestral> And I’m not the only one IIRC? Wasn’t Jyrki having trouble too?
20160725 05:08:23< JyrkiVesterinen> No, I wasn't. I had build failures yesterday only because I was verifying if gfgtdf's boost::bind -> std::bind changes compile with MSVC. (Some of them didn't, and thus I rewrote a bit of code.)
20160725 05:08:43< celmin> That was vultraz, not gfgtdf.
20160725 05:08:57< celmin> BTW, sorry, I completely missed your second commit.
20160725 05:09:00< ancestral> Ah okay
20160725 05:09:10< celmin> Though I'm not sure if that's the right way to handle the exception.
20160725 05:10:39< JyrkiVesterinen> I think it's the right way. If std::stoi() throws an exception, std::transform() is going to stop and the "output" vector is going to remain empty.
20160725 05:10:58< celmin> I understand that.
20160725 05:11:01< JyrkiVesterinen> I thought about putting the try-catch inside the lambda but decided against it.
20160725 05:11:08< celmin> That's what I'm wondering about.
20160725 05:12:05< celmin> I guess I'll merge it as-is. The try-catch could be moved into the lambda later if it's decided that that's more desirable.
20160725 05:12:38< irker339> wesnoth: Jyrki Vesterinen wesnoth:boost_trimming 59e13a066eaa / src/tod_manager.cpp: Implement tod_manager::resolve_random() without Boost.Range (#711) https://github.com/wesnoth/wesnoth/commit/59e13a066eaaa867e6455b27fcae396c0ceacadc
20160725 05:12:50< celmin> Ah, I should've edited the commit message a bit more. Oh well.
20160725 05:15:11< JyrkiVesterinen> At least the boost_trimming branch is now down to zero explicit uses of Boost.Bind. :)
20160725 05:15:34< celmin> No implicit use either, except maybe through other Boost libraries.
20160725 05:15:50< celmin> Well, what I mean there is that I changed bind_void to not use it.
20160725 05:16:21< celmin> If you consider bind_void an explicit use, then you can just ignore what I'm saying here.
20160725 05:17:52-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160725 05:21:13-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160725 05:32:18< irker339> wesnoth: Jyrki Vesterinen wesnoth:boost_trimming 531e05af9e2f / src/tod_manager.cpp: Implement tod_manager::resolve_random() without Boost.Range (#711) https://github.com/wesnoth/wesnoth/commit/531e05af9e2f8feaf036b0d4fed89ae6c44b51da
20160725 05:32:20< irker339> wesnoth: Celtic Minstrel wesnoth:boost_trimming e6b8681de85f / src/ (11 files in 8 dirs): Boost type traits / enable_if -> <type_traits> https://github.com/wesnoth/wesnoth/commit/e6b8681de85f6a71569d57b0551f6c473fb1d611
20160725 05:40:48-!- ggeneral [~ggeneral@46.211.155.23] has joined #wesnoth-dev
20160725 05:44:49< celmin> So vultraz, was there something else I should be doing now?
20160725 05:46:38< Ivanovic> celmin: you should edit pofix.py as well as the cfg files for spelling fixes in the original
20160725 05:46:47< celmin> I think that was wedge009 
20160725 05:46:59< Ivanovic> reason: if you don't do the pofix step, translators need to do extra work to review what was changed
20160725 05:47:43< celmin> I feel like there are some things I could put in pofix, but I can't remember…
20160725 05:49:48-!- mjs-de [~mjs-de@x4db6b606.dyn.telefonica.de] has joined #wesnoth-dev
20160725 05:50:30-!- travis-ci [~travis-ci@ec2-54-198-142-39.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 05:50:31< travis-ci> wesnoth/wesnoth#9937 (boost_trimming - 59e13a0 : Jyrki Vesterinen): The build is still failing.
20160725 05:50:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147102141
20160725 05:50:31-!- travis-ci [~travis-ci@ec2-54-198-142-39.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 05:51:00< celmin> Still failing because of that campaign_server thing.
20160725 05:51:13< celmin> Because I haven't bothered to fix that.
20160725 05:59:46-!- mjs-de [~mjs-de@x4db6b606.dyn.telefonica.de] has quit [Remote host closed the connection]
20160725 06:04:41-!- ggeneral [~ggeneral@46.211.155.23] has quit []
20160725 06:13:17< vultraz> blah, git..
20160725 06:13:19< vultraz> how to do this..
20160725 06:13:39< celmin> Probably git pull --rebase?
20160725 06:13:53< celmin> You need to either stash or commit first.
20160725 06:14:35-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160725 06:15:01< vultraz> pull doesn't work from my cl
20160725 06:15:20< vultraz> need to use the Ui and trying to find the equivalent option
20160725 06:15:26< celmin> Eh?
20160725 06:15:36< celmin> Why doesn't it work?
20160725 06:16:13< vultraz> because it doesn't see my publickey.
20160725 06:16:19< celmin> Oh.
20160725 06:16:28< celmin> You should set it up so that it does, obviously.
20160725 06:16:45< celmin> I did that on my Windows awhile ago, though I don't remember how I did it.
20160725 06:17:26-!- travis-ci [~travis-ci@ec2-54-198-142-39.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 06:17:27< travis-ci> wesnoth/wesnoth#9938 (boost_trimming - e6b8681 : Celtic Minstrel): The build is still failing.
20160725 06:17:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147104071
20160725 06:17:27-!- travis-ci [~travis-ci@ec2-54-198-142-39.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 06:18:29< vultraz> i can get to rebase, but I'm not sure what branch to rebase it against
20160725 06:19:18< celmin> Does it include HEAD as an option? (That's not the right choice, but if it includes that it would probably also include FETCH_HEAD.)
20160725 06:20:06< vultraz> uh... not seeing.. that
20160725 06:20:16< celmin> Not surprising, since it's not a branch.
20160725 06:20:35< vultraz> oh, there's remotes/origin/HEAD
20160725 06:20:41< celmin> Is there an option to pull with rebase?
20160725 06:20:55< celmin> ie, if you go to pull, does it give you the option to rebase.
20160725 06:21:06< vultraz> "launch rebase after fetch"
20160725 06:21:45< vultraz> that just tries to rebase against origin/boost_trimmings :|
20160725 06:21:50< celmin> That sounds like it would be right.
20160725 06:22:02< celmin> Rebasing against origin/boost_trimmings should be right.
20160725 06:22:05< vultraz> oh, there's FETCH_HEAD
20160725 06:23:58< vultraz> looking at this: https://drive.google.com/file/d/0B-mR9s8FduLLS1Z3S0FOcXNsQVE/view?usp=sharing
20160725 06:24:08< vultraz> you didn't merge those two commits marked as 'skip' did you?
20160725 06:26:53< vultraz> oh, i think I got it
20160725 06:27:01< vultraz> damn tgit and its confusing interface sometimes
20160725 06:27:23< celmin> What?
20160725 06:28:08< vultraz> the formula commit shows up as  'pick' because it didn't match remote
20160725 06:28:34< vultraz> i simply had to skip that since i want to use the remote - ie, the force-pushed - version
20160725 06:28:45< celmin> Okay?
20160725 06:29:05< vultraz> building now
20160725 06:29:23< celmin> BTW, I don't really think there's any good reason to change tuples to pairs.
20160725 06:29:50-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160725 06:29:50< vultraz> I think it makes the code a little clearer in those cases.
20160725 06:30:06< celmin> If anything, I'd argue that it's pair that should be changed to tuple (except I wouldn't argue that because it's more convenient to do x.first and x.second than get<0>(x) and get<1>(x).)
20160725 06:30:17< vultraz> I'll push it and let you decide 
20160725 06:33:24< vultraz> celmin: btw, what was the horrible bug?
20160725 06:33:34< celmin> What was it again...
20160725 06:33:48< celmin> Oh yeah, the copy constructor used memcpy.
20160725 06:34:04< celmin> Which means that it stored a pointer to the same string as another variant.
20160725 06:34:16< celmin> Which means that once that variant deleted the string it now had a dangling pointer.
20160725 06:34:57< celmin> The other horrible bug was that list/map variants behaved as if their pointer was already valid, basically copying a vector or map into some arbitrary undefined location in memory.
20160725 06:36:08< vultraz> I wonder why it worked before
20160725 06:36:34< celmin> Because it didn't store a pointer to the list or map.
20160725 06:36:43< celmin> Instead it stored a pointer to a reference-counted wrapper.
20160725 06:37:08< celmin> And the destructor didn't delete it until the reference count was zero.
20160725 06:37:45< vultraz> ah
20160725 06:38:06< celmin> That covers the first bug.
20160725 06:38:31< celmin> I think the second bug was just a ridiculous error when I was removing refcount relics.
20160725 06:38:41< celmin> ie, I did something stupid
20160725 06:41:13-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160725 06:42:28< vultraz> seems there are 4 cases of boost::enable_if stuff
20160725 06:42:31< vultraz> still
20160725 06:42:56< celmin> If they're in the campaign server I don't want to touch them.
20160725 06:43:54< vultraz> floating_point_emulation.hpp:188 and gui/core/event/dispatcher_private.hpp:63 and 84
20160725 06:44:05< vultraz> though the former is boost::enable_if_c
20160725 06:44:09< vultraz> so that may be something different
20160725 06:44:14< vultraz> I just noticed
20160725 06:45:16< celmin> Oh, I skipped floating_point_emulation for the same reason.
20160725 06:45:25< celmin> Because it's not included in the XCode project.
20160725 06:45:36< celmin> I guess I missed dispatcher_private.
20160725 06:47:18< JyrkiVesterinen> Floating_point_emulation.hpp? I think we don't have any intention to support platforms without native floating point support.
20160725 06:47:29< JyrkiVesterinen> Can we just kill floating_point_emulation.hpp with fire?
20160725 06:47:48< celmin> Maybe. I have no idae.
20160725 06:47:49< celmin> ^idea
20160725 06:47:51< vultraz> If it's not needed, sure
20160725 06:48:09< celmin> I've never looked at it.
20160725 06:48:17< celmin> I have no idea if its name is accurate.
20160725 06:49:20< JyrkiVesterinen> On a quick look, it introduces a class called tfloat.
20160725 06:49:32< JyrkiVesterinen> I don't recall seeing it being used anywhere.
20160725 06:49:38< vultraz> ^ telltale mordante code :P
20160725 06:49:50< celmin> Uh. Okay then.
20160725 06:50:08< celmin> Guessing it's also included nowhere?
20160725 06:50:32< irker339> wesnoth: Charles Dang wesnoth:boost_trimming a1f688455505 / src/ (13 files in 6 dirs): Refactor uses of boost::tuple to std::tuple or std::pair as appropriate https://github.com/wesnoth/wesnoth/commit/a1f68845550528a611726ae45416232a8136f4ea
20160725 06:51:12< vultraz> it's in sdl/utils.cpp
20160725 06:53:32< vultraz> ok, now wasn't I supposed to un-const something in campaign_server?
20160725 06:54:01-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160725 06:54:25< vultraz> yeah, looks like it
20160725 06:55:38< irker339> wesnoth: Charles Dang wesnoth:boost_trimming 23c2dd0c9480 / src/campaign_server/campaign_server.hpp: Un-constify a unique_ptr consted in error https://github.com/wesnoth/wesnoth/commit/23c2dd0c94806e57b414e9f344f7261a8bba9736
20160725 06:56:41< wedge009> vultraz: celticminstrel: Are we removing that header we talked about earlier?
20160725 06:56:46< vultraz> which one?
20160725 06:56:53< celmin> Yes, in that branch.
20160725 06:57:04< celmin> Which won't be merged for a few days.
20160725 06:57:12< celmin> vultraz: reference_counted_object.hpp
20160725 06:57:17< vultraz> oh yeah
20160725 06:57:22< vultraz> that's removed in the branch
20160725 06:57:26< wedge009> Okay, I'll check that one.
20160725 06:57:49< vultraz> we still have to figure out why units rush across the map :P
20160725 06:58:38< celmin> Was that in the branch too?
20160725 06:58:45< vultraz> it seems somehow that a given level of accelerated speed is faster, basically
20160725 06:58:47< vultraz> yes
20160725 06:58:48< wedge009> celmin: Oh, this is the one that wasn't your imagination. It was never in the project files to begin with, so it's fine. (:
20160725 06:59:46< vultraz> who knows, maybe it's some performance thing
20160725 07:00:57-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 2252 Yes, 570 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
20160725 07:01:01< vultraz> #45
20160725 07:01:12< JyrkiVesterinen> Nice. :)
20160725 07:01:41-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/24 | Greenlight Votes: 2252 Yes, 570 No, 62 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
20160725 07:02:23< vultraz> nothing was tagged today, right?
20160725 07:02:42< celmin> No, loonycyborg only ran pot-update.
20160725 07:02:48< vultraz> ok
20160725 07:02:53-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/25 | Greenlight Votes: 2252 Yes, 570 No, 62 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
20160725 07:03:51< vultraz> ancestral: any update?
20160725 07:10:49-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20160725 07:12:41< ancestral> vultraz: Can’t build unless someone can address the bind boost issues
20160725 07:13:11< ancestral> or I comment out the boost_static_assert, but I don’t know what the fallout of that will be
20160725 07:13:59< ancestral> If you want me to file a bug in the tracker I can do that. It is a blocker.
20160725 07:14:45< vultraz> ancestral: can you see if you can build the boost_trimmings branch?
20160725 07:14:59< celmin> I don't think it'll help, and anyway that's not going to be in this release.
20160725 07:15:08< celmin> (But feel free to try anyway.)
20160725 07:15:59< vultraz> Well, if it fixes his bug we may have to merge it and postpone the release for testing.
20160725 07:16:04< vultraz> Otherwise, I dunno what to do.
20160725 07:16:17< vultraz> We can't have our macOS packager unable to build
20160725 07:16:21< ancestral> Trying
20160725 07:16:29< celmin> Even if it fixes his bug we've already established that it introduces another one.
20160725 07:16:50< vultraz> oh
20160725 07:16:52< vultraz> yes, of a sort
20160725 07:17:16< ancestral> I can build with the static assert commented out, just don’t know if things will blow up, or nothing bad at all will happen
20160725 07:17:59< celmin> I suppose one way to see if things might blow up might be to replace the static assert with a plain assert.
20160725 07:21:03< ancestral> Same errors
20160725 07:21:23< ancestral> Though, I didn’t do the placeholder substitution
20160725 07:22:11-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 07:22:12< travis-ci> wesnoth/wesnoth#9939 (boost_trimming - a1f6884 : Charles Dang): The build is still failing.
20160725 07:22:12< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147114502
20160725 07:22:12-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 07:32:24< ancestral> Okay, I may have fixed the OS X library location thing
20160725 07:32:39< ancestral> by adding a linker flag -headerpad_max_install_names
20160725 07:34:31< celmin> …what on earth is that.
20160725 07:34:41< celmin> I imagine it would break my build, too.
20160725 07:35:00< celmin> Unless the linker ignores unknown options.
20160725 07:36:49< vultraz> Are you still on 10.7?
20160725 07:37:17< celmin> Yeah
20160725 07:37:25< celmin> And no prospect of upgrading anytime soon
20160725 07:37:48< ancestral> It’s for this: http://stackoverflow.com/questions/1596945/building-osx-app-bundle
20160725 07:38:04< ancestral>  / http://stackoverflow.com/questions/12516877/bundling-dylibs-headerpad-max-install-names-not-working
20160725 07:38:28< ancestral> (You don’t have to read this, but it’s to fix that bug with pointing to the correct libs)
20160725 07:39:41< vultraz> geez
20160725 07:39:47< vultraz> you reeealllyy need a new mac
20160725 07:39:52-!- celticminstrel is now known as celmin|sleep
20160725 07:40:04< celmin> Yup
20160725 07:40:43< celmin> But Wesnoth is still supporting 10.7, so in a way it might be sort of useful that I'm still on that. >_>
20160725 07:40:54< ancestral> Kinda true actually
20160725 07:40:54< vultraz> technically
20160725 07:41:21< vultraz> but 10.12 is coming out soon
20160725 07:41:27< celmin> (It's also supporting WinXP if I recall correctly.)
20160725 07:41:41< vultraz> It does
20160725 07:42:17 * celmin sleepytime
20160725 07:45:49< JyrkiVesterinen> Well, Windows XP is still popular enough to matter.
20160725 07:45:50< JyrkiVesterinen> http://gs.statcounter.com/#desktop-os-ww-monthly-201506-201606
20160725 07:46:02< JyrkiVesterinen> 6,5 % market chare according to StatCounter.
20160725 07:46:33< JyrkiVesterinen> Mac OS X is at 9,95 %, for comparison.
20160725 07:49:49< ancestral> I gotta imagine XP users of Wesnoth are pretty damn few
20160725 07:50:06< ancestral> When did Vista come out? Almost 10 years ago?
20160725 07:50:07-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 07:50:08< travis-ci> wesnoth/wesnoth#9940 (boost_trimming - 23c2dd0 : Charles Dang): The build is still failing.
20160725 07:50:08< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147115186
20160725 07:50:08-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 07:52:08< JyrkiVesterinen> Vista came out in November 2006. It's indeed almost ten years.
20160725 07:52:45-!- Appleman1234 [~Appleman1@KD036012037132.au-net.ne.jp] has quit [Ping timeout: 276 seconds]
20160725 07:54:40< JyrkiVesterinen> vultraz: Test don't build because of boost::tuple -> std::pair changes.
20160725 07:54:41< JyrkiVesterinen> https://travis-ci.org/wesnoth/wesnoth/jobs/147115192
20160725 07:54:53< JyrkiVesterinen> * Tests
20160725 07:57:15-!- Kwandulin [~Miranda@p200300760F60627949834AFD203A8320.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160725 08:06:49< vultraz> oh deer
20160725 08:06:52< vultraz> I forgot to update the tests
20160725 08:18:43-!- JyrkiVesterinen [~jyrki@87-100-136-160.bb.dnainternet.fi] has quit [Quit: Going offline for a couple of hours]
20160725 08:21:45-!- Duthlet [~Duthlet@dslb-188-105-122-010.188.105.pools.vodafone-ip.de] has joined #wesnoth-dev
20160725 08:28:21-!- molt [~molt@46.161.114.253] has joined #wesnoth-dev
20160725 08:48:23-!- Appleman1234 [~Appleman1@KD036012033008.au-net.ne.jp] has joined #wesnoth-dev
20160725 08:48:58-!- Kwandulin [~Miranda@p200300760F606279E476BDA727BE92E7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160725 08:57:29< irker339> wesnoth: Charles Dang resources:master b9df8d8f52f6 / images/wesnoth-logo-text-5760.png: Added large-sized (5760x1920) render of English logo text by Sgt. Groovy https://github.com/wesnoth/resources/commit/b9df8d8f52f6286b01cb072a7f8c1980c3717c7f
20160725 08:57:36< vultraz> Should have committed that months ago
20160725 08:57:42< vultraz> Along with the large-sized logo render.
20160725 09:02:38-!- Bonobo [~Bonobo@2001:44b8:254:3200:21e4:6b3b:3dc2:9205] has quit [Ping timeout: 250 seconds]
20160725 09:06:11-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160725 09:09:13-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160725 09:09:14-!- wedge010 is now known as wedge009
20160725 09:10:27-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160725 09:16:28-!- edgrey [~edgrey@178.204.239.170] has joined #wesnoth-dev
20160725 09:29:20-!- Kwandulin [~Miranda@p200300760F606279E476BDA727BE92E7.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160725 09:30:32-!- boucman_work1 [~boucman@193.56.60.161] has joined #wesnoth-dev
20160725 09:33:11-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 265 seconds]
20160725 10:03:12-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160725 10:12:21-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160725 10:16:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160725 10:29:41-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160725 10:32:02-!- JyrkiVesterinen [~jyrki@87-100-136-160.bb.dnainternet.fi] has joined #wesnoth-dev
20160725 10:41:27-!- Bonobo [~Bonobo@2001:44b8:254:3200:a02b:478a:779d:4013] has joined #wesnoth-dev
20160725 10:44:09-!- nkr [Elite14718@gateway/shell/elitebnc/x-mewjwqyuuwvwivvh] has joined #wesnoth-dev
20160725 10:52:45-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160725 10:54:25-!- gfgtdf [~chatzilla@x4e36ae7a.dyn.telefonica.de] has joined #wesnoth-dev
20160725 10:54:36< gfgtdf> ancestral: did you try replacing std::bind with boost::bind in that line where you got the error from ?
20160725 11:37:16< nkr> Hello
20160725 11:52:55< gfgtdf> nkr: hi
20160725 11:53:28< gfgtdf> vultraz: what heepedn to the 1.13.5 release? was it taged yet ?
20160725 11:56:07< nkr> Do you use osx to work on wesnoth?
20160725 11:56:36< gfgtdf> nkr: no i don't
20160725 11:56:41< gfgtdf> nkr: are there problems on osx ?
20160725 11:58:34-!- irker339 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160725 11:59:10< nkr> Im having trouble compiling
20160725 11:59:20< nkr> (1st compilation)
20160725 12:01:31< gfgtdf> nkr: what exactly is the error ? and which wesnoth version do you use ?
20160725 12:08:39< vultraz> gfgtdf: not yet
20160725 12:08:50< vultraz> ancestral was having build troubles
20160725 12:08:51< gfgtdf> vultraz: somethin lockin it ?
20160725 12:09:06< gfgtdf> vultraz: hmm ok
20160725 12:15:23< nkr> on osx, vultraz?
20160725 12:18:12< vultraz> yes
20160725 12:19:59< nkr> ah cool ill try to reach him
20160725 12:22:10< nkr> should I be trying to compile the master branch anyways?
20160725 12:45:37-!- ggeneral [~ggeneral@46.211.2.122] has joined #wesnoth-dev
20160725 12:45:57< vultraz> sure
20160725 12:47:15-!- ggeneral2 [~ggeneral@46.211.2.122] has joined #wesnoth-dev
20160725 12:49:40-!- ggeneral [~ggeneral@46.211.2.122] has quit [Ping timeout: 244 seconds]
20160725 12:50:08-!- ggeneral2 [~ggeneral@46.211.2.122] has quit [Client Quit]
20160725 12:50:22-!- irker479 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160725 12:50:22< irker479> wesnoth: Charles Dang wesnoth:boost_trimming a64fa31fa119 / src/tests/test_commandline_options.cpp: Attempt to fix command line options test https://github.com/wesnoth/wesnoth/commit/a64fa31fa119346a9a5b185ef4ef47ad045c6541
20160725 12:51:31-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/25 | Greenlight Votes: 2430 Yes, 630 No, 62 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
20160725 12:52:40< vultraz> #44
20160725 12:57:09< gfgtdf> anone has  an idea what util::unique_ptr is for ?
20160725 12:57:20< vultraz> not I
20160725 12:57:58< vultraz> gfgtdf: do you think this can use std:;swap https://github.com/wesnoth/wesnoth/blob/master/src/fake_unit_ptr.cpp#L32
20160725 12:59:58< gfgtdf> vultraz: i think its using boost::swap because, boost::swap has a specialisation for boost::internal_ptr (which is the type of unit_)
20160725 13:00:27< gfgtdf> boost::intrusive_ptr  i meantz
20160725 13:00:58< vultraz> hm ok
20160725 13:03:26< vultraz> gfgtdf: i dont think it's worth refactoring unit_ptr to use a shared_ptr do you
20160725 13:04:18< gfgtdf> vultraz: instrusive_ptr is more efficient that shared_ptr
20160725 13:04:28< gfgtdf> vultraz: thats the reason why instrusive_ptr was used
20160725 13:05:13< gfgtdf> vultraz: note the boost has also had shared_ptr before c++11 , so on all the codes you can assume that intrusive_ptr was intentionally used over shared_ptr.
20160725 13:05:23< vultraz> hm
20160725 13:05:24< vultraz> ok
20160725 13:05:40< gfgtdf> vultraz: i personalyl wouldnt change any of those to use shared_ptr unless you know for wuire that is negletible
20160725 13:06:14< gfgtdf> vultraz: on the other had shared_tr has 2 nice freatures: 1) Its threadsafe ,  2) it support weak_ptr
20160725 13:08:04< vultraz> gfgtdf: do you think it's good to use shared_ptr for GUI2 (like I changed it to) since the loadscreen uses threads?
20160725 13:09:09< gfgtdf> vultraz: hmm no those gui2 intenal object are all inernaly owned by the main thread so there shoudl be no issues replated to threading.
20160725 13:11:08< vultraz> hm
20160725 13:11:09< vultraz> ok
20160725 13:12:06< vultraz> still think at least the formula change is worthwhile
20160725 13:16:47< gfgtdf> vultraz: don't know
20160725 13:26:47-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 13:26:48< travis-ci> wesnoth/wesnoth#9941 (boost_trimming - a64fa31 : Charles Dang): The build is still failing.
20160725 13:26:48< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147178987
20160725 13:26:48-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 13:29:13-!- JyrkiVesterinen [~jyrki@87-100-136-160.bb.dnainternet.fi] has quit [Quit: Konversation terminated!]
20160725 13:37:58-!- esr [~esr@wesnoth/developer/esr] has quit [Read error: Connection reset by peer]
20160725 13:38:51-!- esr [~esr@72.23.56.103] has joined #wesnoth-dev
20160725 13:38:54-!- esr [~esr@72.23.56.103] has quit [Changing host]
20160725 13:38:54-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160725 13:42:27-!- Kwandulin [~Miranda@p200300760F606287F440B3024EF4F7AD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160725 13:44:56-!- esr [~esr@wesnoth/developer/esr] has quit [Ping timeout: 250 seconds]
20160725 13:46:52-!- esr [~esr@72.23.56.103] has joined #wesnoth-dev
20160725 13:46:52-!- esr [~esr@72.23.56.103] has quit [Changing host]
20160725 13:46:52-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160725 14:04:55-!- iceiceice [~chris@50.245.222.235] has joined #wesnoth-dev
20160725 14:04:55-!- iceiceice [~chris@50.245.222.235] has quit [Changing host]
20160725 14:04:55-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160725 14:21:34-!- Bonobo [~Bonobo@2001:44b8:254:3200:a02b:478a:779d:4013] has quit [Ping timeout: 250 seconds]
20160725 14:42:10< irker479> wesnoth: Charles Dang wesnoth:boost_trimming a1788e579d66 / src/tests/test_commandline_options.cpp: Fixup https://github.com/wesnoth/wesnoth/commit/a1788e579d665a55988aca2397d44d7cba3716bf
20160725 14:46:16-!- celmin|sleep is now known as celticminstrel
20160725 14:48:04-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/25 | Greenlight Votes: 2514 Yes, 644 No, 62 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
20160725 14:48:09< vultraz> #41
20160725 14:55:34< irker479> wesnoth: Gregory A Lundberg wesnoth:master 10e008a84114 / src/units/map.cpp: Missing newline on stderr https://github.com/wesnoth/wesnoth/commit/10e008a841145d0b669058203ebb011465a254e5
20160725 14:55:36< irker479> wesnoth: Charles Dang wesnoth:master 0631dfdd00c4 / src/units/map.cpp: Merge pull request #712 from GregoryLundberg/GL_newid https://github.com/wesnoth/wesnoth/commit/0631dfdd00c4cd79c37f0b087739a191047bccd2
20160725 15:42:59-!- Kwandulin [~Miranda@p200300760F606287F440B3024EF4F7AD.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160725 15:55:33-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160725 15:58:51-!- Duthlet [~Duthlet@dslb-188-105-122-010.188.105.pools.vodafone-ip.de] has quit [Quit: leaving]
20160725 15:59:42-!- boucman_work1 [~boucman@193.56.60.161] has quit [Ping timeout: 250 seconds]
20160725 16:09:37-!- travis-ci [~travis-ci@ec2-54-91-68-140.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 16:09:37< travis-ci> wesnoth/wesnoth#9942 (boost_trimming - a1788e5 : Charles Dang): The build is still failing.
20160725 16:09:38< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147208188
20160725 16:09:38-!- travis-ci [~travis-ci@ec2-54-91-68-140.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 16:10:41-!- JyrkiVesterinen [~jyrki@87-100-253-129.bb.dnainternet.fi] has joined #wesnoth-dev
20160725 16:11:27-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160725 16:11:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160725 16:17:46< vultraz> celticminstrel: could you take a look at the cl options text
20160725 16:17:49< vultraz> test
20160725 16:18:08< vultraz> I must have screwed up the syntax on line 285 but I can't see how
20160725 16:20:56-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160725 16:21:00-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160725 16:35:50-!- ggeneral [~ggeneral@46.211.112.194] has joined #wesnoth-dev
20160725 16:37:01< JyrkiVesterinen> I found it: https://github.com/wesnoth/wesnoth/commit/a64fa31fa119346a9a5b185ef4ef47ad045c6541#commitcomment-18381669
20160725 16:41:39< vultraz> thanks
20160725 16:41:46< irker479> wesnoth: Charles Dang wesnoth:boost_trimming 43d5a473e2b2 / src/tests/test_commandline_options.cpp: More fixup https://github.com/wesnoth/wesnoth/commit/43d5a473e2b2ae12b2431296cf90d9819bc85e3e
20160725 16:42:37-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160725 16:50:23< gfgtdf> celmin: do you also have the isue ancestal reported ?
20160725 16:50:54-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160725 16:50:58< celmin> No
20160725 16:51:40< gfgtdf> celmin: are you able to test it? do you nkow why he got the isue and you not (i assume you both use osx) ?
20160725 16:51:56< gfgtdf> know*
20160725 16:52:02< celmin> Probably either a result of different Boost version or different compiler version.
20160725 16:52:38< gfgtdf> celmin: is your cmompiler newer or older than his ?
20160725 16:52:47< celmin> That's a pretty silly question.
20160725 16:53:00< gfgtdf> celmin: why ?
20160725 16:53:55< celmin> I thought it was common knowledge that my Mac is ancient.
20160725 16:54:25< celmin> I could in principle use the latest compiler, but it won't work with my version of XCode.
20160725 16:56:46< gfgtdf> celmin: hmm ok
20160725 17:06:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160725 17:11:11-!- gfgtdf [~chatzilla@x4e36ae7a.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20160725 17:13:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160725 17:29:05-!- ggeneral [~ggeneral@46.211.112.194] has quit [Read error: Connection reset by peer]
20160725 17:32:04-!- ggeneral [~ggeneral@46.211.113.5] has joined #wesnoth-dev
20160725 17:39:03-!- ideuler [~textual@0.213.62.94.rev.vodafone.pt] has joined #wesnoth-dev
20160725 17:46:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160725 17:49:30-!- ggeneral [~ggeneral@46.211.113.5] has quit []
20160725 18:05:43-!- ideuler [~textual@0.213.62.94.rev.vodafone.pt] has quit [Quit: Chakalaka.]
20160725 18:12:58-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20160725 18:14:33-!- Duthlet [~Duthlet@dslb-188-105-122-010.188.105.pools.vodafone-ip.de] has joined #wesnoth-dev
20160725 18:34:07-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160725 18:35:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160725 18:51:06-!- travis-ci [~travis-ci@ec2-54-92-161-76.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 18:51:07< travis-ci> wesnoth/wesnoth#9945 (boost_trimming - 43d5a47 : Charles Dang): The build is still failing.
20160725 18:51:07< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147242555
20160725 18:51:07-!- travis-ci [~travis-ci@ec2-54-92-161-76.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 18:58:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160725 19:20:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160725 19:20:52-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160725 19:34:21-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160725 19:54:00-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 244 seconds]
20160725 19:56:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160725 20:01:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160725 20:02:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160725 20:06:43-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160725 20:07:55-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
20160725 20:10:02-!- JyrkiVesterinen [~jyrki@87-100-253-129.bb.dnainternet.fi] has quit [Quit: Konversation terminated!]
20160725 20:19:31-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160725 20:19:37-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160725 20:25:23-!- irker479 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160725 20:25:40-!- gfgtdf [~chatzilla@x4e36ae7a.dyn.telefonica.de] has joined #wesnoth-dev
20160725 20:27:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160725 20:38:30-!- Nobun [~nobun@host75-49-dynamic.21-87-r.retail.telecomitalia.it] has joined #wesnoth-dev
20160725 20:38:40-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Remote host closed the connection]
20160725 20:54:05-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160725 21:03:23-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 265 seconds]
20160725 21:06:13-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160725 21:06:17-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160725 21:09:57-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160725 21:09:58-!- wedge010 is now known as wedge009
20160725 21:15:11< gfgtdf> celmin: now that i puled form master i also get the erro about ö in commandline
20160725 21:15:20< celmin> ...
20160725 21:15:44< celmin> Okay then.
20160725 21:16:48< gfgtdf> celmin: so it must have been introduces quiet recently
20160725 21:19:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160725 21:29:44-!- mjs-de [~mjs-de@x4e314a31.dyn.telefonica.de] has joined #wesnoth-dev
20160725 21:35:25-!- JordiGH [~jordi@octave/developer/JordiGH] has joined #wesnoth-dev
20160725 21:35:55< JordiGH> So for the Steam thing... it's still GPL, right? You're just charging for distributing the exact same GPL version in Steam?
20160725 21:36:13< celmin> Charging? Where did you get this from?
20160725 21:36:34< JordiGH> I thought that's what greenlight was.
20160725 21:36:56< celmin> Greenlight is for getting a game on Steam.
20160725 21:37:41< celmin> Anyway, the Steam version will be the same as the non-Steam version, except insofar as it supports Steam features (eg cloud saves).
20160725 21:42:45< JordiGH> And... it costs money?
20160725 21:42:56< JordiGH> Or can you have gratis games on Steam?
20160725 21:43:06< Aginor> JordiGH: "free to play" is a category
20160725 21:43:11< celmin> You can have free games on Steam, yes.
20160725 21:43:22-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 scheduled for 7/25 | Greenlight Votes: 2809 Yes, 709 No, 62 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
20160725 21:43:28< vultraz> #35
20160725 21:43:42< Aginor> afaik, there's no plans to charge money, or change the licensing of the game
20160725 21:43:55< Aginor> vultraz: it's the 26th, where's the release? :D
20160725 21:44:18< celmin> If the topic is to be believed, it's been delayed a whole month.
20160725 21:44:31< Aginor> 1.13.5 scheduled for  7/25 
20160725 21:44:41< celmin> Right, 7th day of the 25th month.
20160725 21:44:44< Aginor> yeah
20160725 21:44:47< vultraz> :| you people
20160725 21:44:51< celmin> Before it was 24th month.
20160725 21:44:58< Aginor> I am willing to try to interpret that backwards though
20160725 21:45:04< Aginor> and go with "yesterday" :D
20160725 21:45:33< JordiGH> Hm, why not charge money for the game without changing the licensing?
20160725 21:45:51< vultraz> Aginor: I'll try to make sure it's tagged today
20160725 21:45:54< celmin> Anyway, that aside, I'm not really sure whether it was stopped because of a blocker or if loonycyborg just didn't get around to it.
20160725 21:46:04< celmin> JordiGH: While certainly a possibility, it seems that wasn't the intent.
20160725 21:46:30< JordiGH> You think people would be offended?
20160725 21:46:37< celmin> I have no idae.
20160725 21:46:40< celmin> idae
20160725 21:46:42< celmin> ...idea
20160725 21:46:48< JordiGH> Or someone else would just upload the game again but making it gratis?
20160725 21:47:05< vultraz> JordiGH: we didn't feel we could justify charging for the game
20160725 21:47:13< JordiGH> Huh, why not?
20160725 21:47:24< celmin> Well, if cost money on Steam, there would be little to no reason to download it on Steam.
20160725 21:47:30< JordiGH> Wasn't there already a version for sale on Android once?
20160725 21:47:34< celmin> When a free version is available on the website.
20160725 21:47:44< vultraz> Yes, we change for the Android and iOS ports
20160725 21:48:04< JordiGH> Isn't there some benefit to Steam? I thought maybe it integrated nicely with other things.
20160725 21:48:14< JordiGH> Why do people want it on Steam at all, with or without pay?
20160725 21:48:24< celmin> It's to increase exposure.
20160725 21:48:43< celmin> By putting it on Steam, you reach people who are unlikely to have discovered it otherwise.
20160725 21:48:46< zookeeper> apparently some people like to have all their games on steam, or something. and for exposure too.
20160725 21:48:52< JordiGH> I think you should charge for the steam version. One dollar or whatever a small amount.
20160725 21:48:54< celmin> That too, probably.
20160725 21:49:24< JordiGH> "Free to play" sounds too much like "we're gonna trick you to buy things in the game".
20160725 21:49:44< vultraz> that is not true
20160725 21:49:45< celmin> I disagree, but whatever.
20160725 21:49:53< gfgtdf> vultraz: what exactly did #696 fix ?
20160725 21:49:59< celmin> It's true that some "free to play" games charge for microtransactions.
20160725 21:50:22< vultraz> gfgtdf: crashes
20160725 21:51:04< loonycyborg> celmin: I didn't work on tagging because vultaz didn't tell me to, since apparently there are some problems to sort out yet
20160725 21:51:09< gfgtdf> vultraz: hmm i think that it causes an ö to appera in commandline (that i have to remove manually) when i use it.
20160725 21:51:16< vultraz> wha???
20160725 21:51:18< celmin> So there were some problems then?
20160725 21:51:34< celmin> Okay, so apparently the event context changes are causing the ;debug problem?
20160725 21:51:41< celmin> Reverting them is not an option though.
20160725 21:51:56< gfgtdf> celmin: i just reverted them locally and that problem disappeared.
20160725 21:52:22< celmin> But they were done to fix other crashes, so reverting is not an option.
20160725 21:52:38< vultraz> gfgtdf: we cannot revert that
20160725 21:52:54< Aginor> either we release-note it or we fix it
20160725 21:53:05< gfgtdf> vultraz: i did say we shodul revert it i just explained wha i think that its the casue for the issue
20160725 21:53:13< celmin> It seems a relatively minor bug, so I think putting it in release notes would be fine.
20160725 21:53:43< celmin> What was the issue preventing release? Was it ancestral's compile errors or something else?
20160725 21:54:00< gfgtdf> vultraz: can you explain what exactly casued the crash previously ?
20160725 21:54:15< vultraz> Aginor can do that in more detail
20160725 21:54:19-!- JordiGH [~jordi@octave/developer/JordiGH] has left #wesnoth-dev ["Leaving"]
20160725 21:54:29< vultraz> but tl'dr the vector was being modified somewhere else
20160725 21:55:07< Aginor> gfgtdf: multiple potential entry points that could cause a vector to be modified while another part was iterating over it, leading to invalid iterators and crashes
20160725 21:55:32< Aginor> gfgtdf: we changed vectors to linkedlists
20160725 21:55:57< Aginor> I wonder if the extra letter is an inadvertant regression in the focus handling code
20160725 22:01:07-!- irker879 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160725 22:01:07< irker879> wesnoth: Charles Dang wesnoth:boost_trimming 83861cdc4b22 / src/tests/test_formula_core.cpp: Fixup formula tests https://github.com/wesnoth/wesnoth/commit/83861cdc4b2291eae807e4a7f843d7b2d0766612
20160725 22:02:36< gfgtdf> Aginor: hmm ok
20160725 22:03:03-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160725 22:03:29< gfgtdf> vultraz: its also the 26 here now, ad still no release
20160725 22:03:54< vultraz> gfgtdf: as soon as I confirm ancestral can build I'll ask loonycyborg to tag
20160725 22:04:20< gfgtdf> vultraz: was any attempt made to fix ancestrals issue ?
20160725 22:05:09< gfgtdf> vultraz: i mean is see nothign related in the commit history
20160725 22:05:18< vultraz> we don't exactly know how to fix it
20160725 22:05:34< celmin> Someone suggested changing those cases to boost::bind.
20160725 22:05:52< celmin> I'd rather not do that, but...
20160725 22:06:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160725 22:06:21< gfgtdf> changing to use lamdas might will mostlikeley wokr too
20160725 22:06:30< celmin> Ehh...
20160725 22:06:48< celmin> It's true that that would fix the issue, though.
20160725 22:07:12< celmin> I don't like it, but if it's a question of whether someone can compile at all, I guess we can do it.
20160725 22:07:24< celmin> There was a list of the instances linked in here somewhere...
20160725 22:07:29< Aginor> how about us putting a feature freeze in place, aiming to release this weekend and properly try to fix the worst of bugs before then?
20160725 22:07:44< pydsigner> Is Gregory Lundberg in this channel?
20160725 22:07:57< celmin> No, he generally doesn't come by unless he has a specific purpose.
20160725 22:08:06< vultraz> celmin: what's wrong with lambdas?
20160725 22:08:08< celmin> (He seems to use the nick "tad".)
20160725 22:08:23< celmin> vultraz: They're just not really an improvement over bind.
20160725 22:08:28< pydsigner> celmin: Ok thanks
20160725 22:08:34< Aginor> where top priority should be anything that stops packagers from packaging, crashes or bad UI issues
20160725 22:08:56-!- Nobun [~nobun@host75-49-dynamic.21-87-r.retail.telecomitalia.it] has quit [Quit: Salve a tutti]
20160725 22:09:09-!- vultraz changed the topic of #wesnoth-dev to: Feature freeze in effect. 1.13.5 scheduled for 7/31 or earlier pending blocker fixes | Greenlight Votes: 2809 Yes, 709 No, 62 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
20160725 22:10:11< gfgtdf> not its 31.7 ??
20160725 22:10:13< gfgtdf> now*
20160725 22:10:18< vultraz> :|
20160725 22:10:38< celmin> So now it's the 31st month.
20160725 22:10:47< celmin> The year keeps getting longer and longer.
20160725 22:10:59< Aginor> celmin: mars
20160725 22:11:09< Aginor> I heard the calendar there is long
20160725 22:11:22< celmin> The Martian calendar I've heard of is 24 months.
20160725 22:11:37< gfgtdf> also i dont reqalyl see  a reason for a featuire freeze, since features are usually not more likeley to introduce new bugs that refactors or other bugfixes
20160725 22:12:12< gfgtdf> than*
20160725 22:12:16< celmin> ...
20160725 22:13:21-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20160725 22:16:16< Aginor> gfgtdf: by feaure freeze I really meant "freeze everything that's not explicitly fixing high priority bugs"
20160725 22:16:45< Aginor> vultraz: you can't just change the topic like that though unless we all agree and think it's a good idea
20160725 22:16:52< Aginor> as it requires commitment from all of us
20160725 22:17:16< vultraz> I did say"or earlier"
20160725 22:19:16< celmin> Someone mentioned steam controller support...
20160725 22:20:04< celmin> Pretty sure Wesnoth doesn't currently support controllers (or if it does, not well).
20160725 22:21:57< Aginor> celmin: there's some unfinished support for it
20160725 22:22:16< Aginor> I even took it out of the hotkey system and haven't reintroduced it yet
20160725 22:22:16< celmin> Emphasis on unfinished.
20160725 22:22:21< celmin> Oh, I see.
20160725 22:22:35< Aginor> it'd be trivial, but the rest of the controller support is pretty crap so I didn't bother
20160725 22:22:41< celmin> Eh?
20160725 22:23:00< Aginor> you could use a button to bring up the recruit menu or something
20160725 22:23:03< Aginor> but that's about it
20160725 22:23:13< celmin> I don't really know anything about controller support, but do you think it could be ready for the Steam release?
20160725 22:23:29< Aginor> I don't think wesnoth is a controller game at all
20160725 22:23:32< celmin> True.
20160725 22:23:47< Aginor> steam controller can act as mouse+keyboard, supposedly
20160725 22:23:57< Aginor> if they sold them in NZ I would be able to tell you
20160725 22:24:10< celmin> Steam controller is a specific controller?
20160725 22:24:32-!- mjs-de [~mjs-de@x4e314a31.dyn.telefonica.de] has quit [Remote host closed the connection]
20160725 22:24:57< Aginor> celmin: yes
20160725 22:25:01< celmin> Huh, okay.
20160725 22:25:21< Aginor> as opposed to generic xbox360-lookalike that's popular nowadays
20160725 22:36:23< vultraz> the 360 is so last-gen
20160725 22:38:10< Aginor> so is next-gen
20160725 22:38:59< vultraz> next-gen is this-gen
20160725 22:39:26< Aginor> hmm
20160725 22:39:32< Aginor> amazon sells the controllers
20160725 22:39:38< Aginor> maybe I should order a couple
20160725 22:39:53< celmin> Really?
20160725 22:39:56-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160725 22:39:56-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160725 22:40:29< Aginor> celmin: amazon us
20160725 22:40:44< celmin> No, my surprise was more that you were considering buying them.
20160725 22:41:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160725 22:46:25-!- travis-ci [~travis-ci@ec2-54-158-129-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 22:46:26< travis-ci> wesnoth/wesnoth#9946 (boost_trimming - 83861cd : Charles Dang): The build is still failing.
20160725 22:46:26< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147314607
20160725 22:46:26-!- travis-ci [~travis-ci@ec2-54-158-129-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 22:51:48-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160725 22:56:50-!- Duthlet [~Duthlet@dslb-188-105-122-010.188.105.pools.vodafone-ip.de] has quit [Quit: leaving]
20160725 23:00:58< irker879> wesnoth: Charles Dang wesnoth:boost_trimming 0f6eaffd5262 / src/tests/test_mp_connect.cpp: Fixup mp connect tests https://github.com/wesnoth/wesnoth/commit/0f6eaffd52628d893b7bf4f78fb5ad2a2862cd6c
20160725 23:01:42< celmin> Did you fix the misplaced const in the campaign_server yet?
20160725 23:02:09< vultraz> yes
20160725 23:02:29< Aginor> celmin: how come?
20160725 23:02:43< celmin> Uh. I dunno.
20160725 23:02:46< Aginor> I'm interested in a steam link too
20160725 23:02:57< Aginor> so I might put in an expensive steam order ;)
20160725 23:03:08< Aginor> s/steam order/amazon order/
20160725 23:03:24< Aginor> although I have to watch out so I don't get stung by customs :/
20160725 23:04:05< vultraz> customs?
20160725 23:04:15< vultraz> oh, right, foreign country
20160725 23:44:36-!- travis-ci [~travis-ci@ec2-54-91-68-140.compute-1.amazonaws.com] has joined #wesnoth-dev
20160725 23:44:37< travis-ci> wesnoth/wesnoth#9947 (boost_trimming - 0f6eaff : Charles Dang): The build is still failing.
20160725 23:44:38< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/147325270
20160725 23:44:38-!- travis-ci [~travis-ci@ec2-54-91-68-140.compute-1.amazonaws.com] has left #wesnoth-dev []
20160725 23:50:41< vultraz> ok what's wrong now :|
20160725 23:51:34-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160725 23:52:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160725 23:52:15< irker879> wesnoth: Charles Dang wesnoth:boost_trimming 9be7a6d24683 / src/tests/test_mp_connect.cpp: Fixup mp tests https://github.com/wesnoth/wesnoth/commit/9be7a6d246839a08f635bcdbd07d9a3913c23a7a
--- Log closed Tue Jul 26 00:00:34 2016