--- Log opened Tue Sep 06 00:00:41 2016
20160906 00:08:20< mattsc> tad_, celmin: I’ve been away for the last few hours and don’t have time to read up on the logs right now either.  Is there anything specific you want me to do?
20160906 00:08:48< mattsc> I mean, if you two C++ wizards cannot figure it out (so far), I’m not sure what I could possibly do.
20160906 00:09:15< celmin> Huh, when did I become a wizard.
20160906 00:09:42< mattsc> Leveled up through sufficient number of kills.
20160906 00:12:41< celmin> Hmm, so it seems like I broke listboxes.
20160906 00:14:04< vultraz> well that's not good
20160906 00:14:27< celmin> More specifically, listbox scrollbars.
20160906 00:19:05 * vultraz is refactoring tgroup
20160906 00:22:06< celmin> I have "virtual thunk to gui2::policy::…" in my stack trace.
20160906 00:26:23< celmin> I wonder if that's because of the multiple inheritance, or because of the virtual inheritance.
20160906 00:27:41< celmin> … items < visible_items can't be good.
20160906 00:27:52< celmin> Though, that's not the one that was broken.
20160906 00:28:44< tad_> mattsc: As I told celmin, I'm simply hoping for a face-palm from someone who knows more before I start probing and debugging.
20160906 00:31:25< celmin> Oh wait, I guess visible_items is more like "how many items could be visible" rather than "how many items actually are visible", so maybe it's not a problem then.
20160906 00:33:26< mattsc> tad_: okay, I’ll have a look later tonight; but as you know (I think), while I know AI behavior really well, I don’t know much at all about the AI code.
20160906 00:33:38< mattsc> uh ...
20160906 00:33:50< mattsc> s/really/reasonably  — that’s kind of embarrassing  :P
20160906 00:34:32< tad_> Take a look at my issue then and if some of my test cases are doing something dumb, let me know.
20160906 00:34:45< mattsc> will do
20160906 00:36:31< celmin> I think my problem is probably that get_height() doesn't return what I thought it did.
20160906 00:38:01< celmin> …what the heck is get_call_stack()? o.o
20160906 00:38:06< vultraz> it'd be nice if map had map::find_if
20160906 00:39:44< vultraz> instead of just find
20160906 00:40:22< celmin> Not a big deal though, just use std::find_if.
20160906 00:40:55-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160906 00:44:53< vultraz> celmin: I assume the predicate argument would be the map value type?
20160906 00:45:13< celmin> The predicate is always the value_type.
20160906 00:45:32< celmin> Note that for a map, the value_type is pair<const key_type, mapped_type>.
20160906 00:46:31< vultraz> blah
20160906 00:46:36< vultraz> yeah, not worth using that
20160906 00:46:41< vultraz> range-for it is
20160906 00:46:42< celmin> Sure it is?
20160906 00:47:00< celmin> Don't use range-for for "find if"… :|
20160906 00:47:08< vultraz> obv not
20160906 00:47:12< vultraz> for + if()
20160906 00:47:18< celmin> What?
20160906 00:47:39< vultraz> simpler to just iterate over the map and check each value
20160906 00:47:55< celmin> What are you doing? :|
20160906 00:48:13< vultraz> i was refactoring tgroup to be a map.
20160906 00:48:22< vultraz> sadly it didn't simply stuff as much as I'd hoped
20160906 00:48:37< celmin> Why would it be a map?
20160906 00:48:45< vultraz> because it was already a vector of pairs
20160906 00:49:04< celmin> You can't just replace a vector of pairs with a map.
20160906 00:49:15< celmin> (I don't remember what this vector of pairs was in this case though.)
20160906 00:49:22< vultraz> before it was vector<pair<tselectable_*, T>>. I've made it map<T, tselectable_*>
20160906 00:49:32< celmin> What's T?
20160906 00:49:38< vultraz> template
20160906 00:49:48< celmin> Obviously, I mean what does it represent.
20160906 00:49:52< vultraz> tgroup is a template class, remember
20160906 00:49:59< vultraz> bound group value
20160906 00:50:05< vultraz> widget*
20160906 00:50:26< vultraz> I figured it'd be good to allow access to the widgets by value
20160906 00:50:56< celmin> Okay, so that means you can't have multiple widgets with the same value, which probably means you should give an error message if you try to add a widget with a value that already exists in the map.
20160906 00:51:19< vultraz> one would not want such a thing anyway
20160906 00:51:28< celmin> You might, but it'd be pretty rare.
20160906 00:51:36< celmin> So, error message.
20160906 00:51:39< vultraz> anyway, I was kinda hoping I could simplify some of these loops
20160906 00:51:43< vultraz> but turns out I cannot
20160906 00:52:15< celmin> Also, using a map means the bound type needs to be comparable.
20160906 00:52:18< vultraz> since I always need to check something in the tselectable_* (ie, map.second)
20160906 00:52:28< celmin> Which wasn't the case with the vector,
20160906 00:53:01< vultraz> in fact all the operations are on .second
20160906 00:53:43< vultraz> sadness :(
20160906 00:54:23< celmin> The loops all look pretty simple to me.
20160906 00:54:36< celmin> And all the operations are on .first, of course
20160906 00:54:46< vultraz> i swapped the order
20160906 00:54:53< celmin> Yeah I know, I'm looking at current.
20160906 00:55:15< celmin> So how are you supposed to simplify a one-line loop?
20160906 00:56:09< vultraz> one cannot
20160906 00:56:38< celmin> Then what loops were you hoping to simplify?
20160906 00:57:28< vultraz> i was hoping this could be implemented more cleanly http://pastebin.com/imtYx8Rk
20160906 01:01:57< celmin> Looks fairly clean to me? What are your problems with it?
20160906 01:03:47< vultraz> eh, ignore me
20160906 01:06:02< vultraz> (should I be using .emplace for adding a new member to guard against duplicate addition?)
20160906 01:07:08< celmin> What?
20160906 01:07:35< vultraz> should i be using emaplce s/...//
20160906 01:07:41< celmin> Using insert/emplace would be one way to guard against duplicates.
20160906 01:07:52< celmin> The other way is trying find() first.
20160906 01:08:37-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160906 01:09:02< vultraz> got it
20160906 01:09:03< celmin> insert/emplace return a pair of the iterator to the element and whether the insertion succeeded.
20160906 01:09:26< celmin> So you could use std::tie for example.
20160906 01:09:35< vultraz> hm.. .at() throws an exception
20160906 01:09:40< vultraz> std::tie?
20160906 01:09:42< vultraz> what?
20160906 01:09:43< celmin> Yes, yes it does.
20160906 01:10:14< vultraz> (would rather do find() than try/catch)
20160906 01:12:22< celmin> bool did_insert; std::tie(std::ignore, did_insert) = items.emplace(value, widget); if(!did_insert) print_error();
20160906 01:12:35< vultraz> btw, a benefit of map is being able to do group.members()[value]->stuff 
20160906 01:12:36< celmin> If you want to use emplace rather than find, that's how you'd do it.
20160906 01:12:42< celmin> Yes, I noticed that too.
20160906 01:12:45< vultraz> (though should likely use .at())
20160906 01:12:52< celmin> Probably.
20160906 01:13:04< celmin> Actually yes, use at, because [] inserts the element.
20160906 01:13:20< celmin> And you don't want to risk littering the map with a bunch of null pointers.
20160906 01:14:01-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160906 01:14:44-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 01:18:33< vultraz> hm... it's possible to end up with no item in the group selected
20160906 01:18:39< vultraz> not what i inended 
20160906 01:18:41< vultraz> intended
20160906 01:18:55< vultraz> perhaps the reselection thing should be called by the dialog?
20160906 01:19:29< celmin> Well, if all items get disabled, then yes, you'd end up with no item selected.
20160906 01:20:58< vultraz> they're not all disabled
20160906 01:21:47< celmin> Then how do you end up with no item selected?
20160906 01:21:48< vultraz> oh...
20160906 01:21:50< vultraz> hm
20160906 01:22:03< vultraz> hmmm
20160906 01:22:23< vultraz> for some reason, if you select a female-only unit, and then the boat, nothing will be selected
20160906 01:22:32< celmin> Why?
20160906 01:22:34< vultraz> (boat as in the Boat unit)
20160906 01:22:43< vultraz> I'm not sure..
20160906 01:22:53< celmin> Boats should have a "male" gender.
20160906 01:23:04< vultraz> yes, the button is not disabled
20160906 01:23:07< vultraz> just not selected
20160906 01:23:09< celmin> Oh, I think I have an idea.
20160906 01:23:18< vultraz> hm
20160906 01:23:27< vultraz> it happens any time i switch back to a male-only unit
20160906 01:23:30< celmin> What you need to do is make sure you enable things before disabling things, I think.
20160906 01:23:44< celmin> Otherwise there is a period of time where all of them are disabled.
20160906 01:23:57< celmin> Though I'd expect your code to select the newly-enabled one then...
20160906 01:24:07< celmin> Oh right, because that only runs if you're disabling.
20160906 01:25:17< vultraz> let me try restoring the conditional..
20160906 01:25:24< vultraz> (I had inverted it to reduce a level of indent)
20160906 01:30:58-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 01:32:31< vultraz> ..ok I don't understand this :/
20160906 01:33:49< celmin> I'm at a loss for how to calculate a listbox's visible vs full area from the generator.
20160906 01:38:31< vultraz> i swear this was working earlier...
20160906 01:38:43< celmin> That has happened to me before, too.
20160906 01:41:03-!- ancestral [~ancestral@75.168.189.115] has joined #wesnoth-dev
20160906 01:51:08< vultraz> (for the record, even with the vector implementation the values needed to be comparable)
20160906 01:51:22< celmin> They did?
20160906 01:51:30< vultraz> yes
20160906 01:51:38< celmin> Where?
20160906 01:52:04< vultraz> set_member_states relied on comparing the passed value with the value of the widget/value pair
20160906 01:52:10-!- ancestral [~ancestral@75.168.189.115] has quit [Quit: i go nstuf kthxbai]
20160906 01:52:24< celmin> No it didn't?
20160906 01:52:38< vultraz> ?
20160906 01:52:39< celmin> Note that "comparable" is stricter than "equality-comparable".
20160906 01:52:46< celmin> And implies operator<
20160906 01:52:49< vultraz> I see
20160906 01:52:53< celmin> And > and <= and >=
20160906 01:58:56< vultraz> hm..
20160906 01:59:22< vultraz> if(dynamic_cast<tcontrol*>(member.second)->get_active())
20160906 01:59:27< vultraz> not passing for some reason..
20160906 01:59:34< vultraz> which is why the new selection isn't selecting..
20160906 02:01:59< celmin> That also risks dereferencing a null pointer, though I think pretty much every widget is a control...
20160906 02:02:59< celmin> Maybe it'd be better to cast by reference.
20160906 02:08:47< vultraz> i have no idea what happened :|
20160906 02:08:51< celmin> Trying to decipher this.
20160906 02:08:51< vultraz> it was working earlier
20160906 02:09:45< celmin> It seems like each widget references back to its "parent"?
20160906 02:09:57< celmin> So the parent of the generator is… a grid. Not the listbox.
20160906 02:10:11< celmin> Then the parent of that grid is the listbox.
20160906 02:10:27< vultraz> keep in mind the generator swaps grids
20160906 02:10:45< celmin> Huh?
20160906 02:11:17< celmin> So the value I need is in the listbox, as content_
20160906 02:11:27< celmin> Which is a spacer.
20160906 02:11:32< celmin> For… some reason.
20160906 02:11:55< celmin> Should I hack in through the parent structure and "hope"?
20160906 02:12:09< vultraz> no idea
20160906 02:12:10< celmin> I think it's only listboxes that use these generators anyway...
20160906 02:12:18< vultraz> multipage?
20160906 02:12:38< celmin> I think that uses tindependent.
20160906 02:14:46< vultraz> gahhh!
20160906 02:14:49< vultraz> what's going on here :|
20160906 02:14:58< celmin> Magic! :O
20160906 02:15:03< celmin> Dark magic!
20160906 02:15:10< vultraz> why should get_active be false for all widgets!
20160906 02:15:46< vultraz> and why did it work earlier!
20160906 02:15:50< celmin> Hmm, maybe what I need to do is offload part of the work to the tlistbox.
20160906 02:15:53< celmin> Hmm hmm hmm.
20160906 02:15:55< celmin> Can I do that.
20160906 02:16:22< celmin> I think maaaybe I can...
20160906 02:21:13< mattsc> celmin: so I looked into the issue found by tad_ a bit.
20160906 02:21:36< mattsc> I can make the crash happen, although just after reloading and starting from the Turn 1 save.
20160906 02:21:42< celmin> I see.
20160906 02:21:44< mattsc> Then I did some brute-force debugging.
20160906 02:21:50< mattsc> The crash happens here:
20160906 02:21:53< celmin> And that was attack depth commented out?
20160906 02:21:57< mattsc> https://github.com/wesnoth/wesnoth/blob/master/src/ai/default/ca.cpp#L598
20160906 02:22:08< mattsc> and in that function here:
20160906 02:22:09< mattsc> https://github.com/wesnoth/wesnoth/blob/master/src/ai/contexts.cpp#L1032
20160906 02:22:20< celmin> Hmm, that's a different location than tad found...
20160906 02:22:42< mattsc> maybe it’s not the same crash, I don’t know
20160906 02:22:56< mattsc> I can make it happen with attack_depth both there or not
20160906 02:23:02< celmin> Seems like a different one, but might have the same underlying cause?
20160906 02:23:11< mattsc> yeah, maybe
20160906 02:23:22< celmin> From that I would deduce that get_avoid() is a likely cause...
20160906 02:23:22< mattsc> I have no idea if this information is useful to you, but that’s what I found
20160906 02:23:33< celmin> Not sure whether this helps...
20160906 02:24:28-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 02:25:04< mattsc> right
20160906 02:27:11< mattsc> The strange thing is that the error message is “UNKNOWN aspect[village_value*ai_default_rca::aspect_attacks]”
20160906 02:27:20< mattsc> HTH does it mix those two aspects together?
20160906 02:27:38< celmin> The format is aspect_name*aspect_type
20160906 02:28:12< mattsc> and village_value is of type aspect_attacks?
20160906 02:28:14< celmin> aspect_name is the id attribute and aspect_type is the name attribute.
20160906 02:28:25< celmin> No, they're not linked in that sort of way.
20160906 02:28:49< mattsc> then I don’t understand what the thing inside the [] is telling me
20160906 02:29:20< celmin> You would get that error if your config had an [aspect] with id=village_value and name=ai_default_rca::aspect_attacks
20160906 02:30:04< celmin> Normally the aspect type is composite_aspect (for an [aspect] tag), simple_aspect (for a [facet] tag), or lua_aspect (for an [aspect] or [facet] with engine=lua).
20160906 02:30:09< mattsc> okay; so how does that happen?
20160906 02:30:19< celmin> However, the attacks aspect cannot be a simple aspect, and thus has its own unique type.
20160906 02:31:04< celmin> Since the config does not (as far as I know) actually contain an aspect with that id and name, my guess would be that memory is getting corrupted somehow, eg by an out-of-bounds array access.
20160906 02:31:26< mattsc> Hmm, I see.
20160906 02:32:02< mattsc> So that might also explain why we’re getting a problem with get_avoid() even though no [avoid] aspect is set in that scenario
20160906 02:32:12< celmin> Could be, yeah.
20160906 02:33:20< celmin> XCode 7 apparently introduces a GUI way to enable address sanitizer, by the way: http://useyourloaf.com/blog/using-the-address-sanitizer/
20160906 02:33:31< celmin> I'm not sure if that would help debug this, but...
20160906 02:34:01< mattsc> hmm...
20160906 02:34:27-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 02:34:31< vultraz> aren't you on xcode 4 still
20160906 02:34:38< celmin> I am, yes, but mattsc is not.
20160906 02:34:46< celmin> Not sure if he's on 7 or 6 though.
20160906 02:34:50< mattsc> Btw, one other bit of information I found is that when you look at the output from —log-debug=ai/*, the engine is trying to set up village_value three times
20160906 02:34:59< mattsc> Also, in the inspector, it appears 3 times
20160906 02:35:17< celmin> Wait… what?
20160906 02:35:18< mattsc> 7.3.1
20160906 02:35:23< celmin> When you say it appears 3 times...
20160906 02:35:30< celmin> Do you mean there are three [aspect] tags for it?
20160906 02:35:37< mattsc> no, three [facet] tags
20160906 02:35:46< celmin> Oh, okay, that's not that weird then.
20160906 02:35:47< mattsc> identical, for all I can tell
20160906 02:35:57< vultraz> ahhhg
20160906 02:36:02< vultraz> still not working
20160906 02:36:03< vultraz> ;_;
20160906 02:36:11< celmin> Especially if this is after a modify_side, which only adds aspects.
20160906 02:36:17< mattsc> but it’s only set once in the scenario, AFAICT
20160906 02:37:03< mattsc> oh, right, it is in there at least twice
20160906 02:37:05< vultraz> I think this only worked when an actual widget was passed..
20160906 02:37:08< vultraz> this is odd,,
20160906 02:37:36< celmin> vultraz: What is the value type, BTW?
20160906 02:37:39< vultraz> ?
20160906 02:37:47< mattsc> which reminds me that I wanted to try something else ...
20160906 02:37:47< celmin> T, what is it?
20160906 02:37:57< vultraz> unit_race::GENDER
20160906 02:38:39< celmin> Hmm, that seems like it should work.
20160906 02:39:02< vultraz> it's the get_active check that's failing
20160906 02:39:09< vultraz> ima go get lunch... investigate later
20160906 02:39:27< mattsc> celmin: no, nothing new
20160906 02:39:42< mattsc> except that I now managed to get the bad lexical cast problem tad_ reported on.
20160906 02:41:03< mattsc> But that’s just because I didn’t wait long enough last time.
20160906 02:41:37< mattsc> celmin: so, for all I know about these things, it looks like something gets screwed up with memory or pointers or something.
20160906 02:42:24< celmin> I'm not certain, but that does seem the most likely cause.
20160906 02:42:47-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 02:43:18< mattsc> celmin: I need to be off again right now.  I’ve bookmarked the sanitizer link and can check that out later (probably tomorrow)
20160906 02:44:47< mattsc> celmin: I just started recompiling with the sanitizer option enable.
20160906 02:45:44< mattsc> What do I do for the debugging?  Start Wesnoth from Xcode?
20160906 02:49:01-!- JyrkiVesterinen [~JyrkiVest@87-100-145-177.bb.dnainternet.fi] has joined #wesnoth-dev
20160906 02:51:33< celmin> Yeah.
20160906 02:56:45-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160906 02:58:59-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 03:00:00< tad_> reading back over the logs looks like Im not theonly one getting confused with what's happening with the AI aspects and facets.
20160906 03:00:28< mattsc> yep
20160906 03:01:45< tad_> I tried comparing two runs and sort of expected the ai results would be much the same. But I'm seeing differences which don't make sense. time-of-day stuff changing .. other stuff which seem unrelated.
20160906 03:02:43< mattsc> celmin, tad_: I compiled with the sanitizer on and ran, getting the crash, but there’s no output other than what I can see in the console also.
20160906 03:03:47-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 03:03:48< mattsc> tad_: yeah, that seems consistent with me getting a crash when the [avoid] aspect is queried.
20160906 03:04:06< mattsc> But I really have to be off now.  Sorry, guys.
20160906 03:04:12< tad_> 'sok
20160906 03:04:48< tad_> I was just thinking I'm spinning my wheels on it. Maybe the best thing is to get celmin to finish that branch and debug it then.
20160906 03:06:37-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160906 03:10:03< celmin> What's the last hotkey in the list?
20160906 03:11:18< celmin> vultraz: ^
20160906 03:13:01< JyrkiVesterinen> 20160906 00:50:56< celmin> Okay, so that means you can't have multiple widgets with the same value, which probably means you should give an error message if you try to add a widget with a value that already exists in the map.
20160906 03:13:17< JyrkiVesterinen> There is std::multimap, an associative container that can map multiple values to one key.
20160906 03:13:34< celmin> Yes, I know, but it didn't seem like what was needed here.
20160906 03:13:59< celmin> (It also doesn't have operator[], for what are probably obvious reasons.)
20160906 03:16:13< celmin> Did you have any plans to change attack prediction to a sparse array?
20160906 03:18:27< JyrkiVesterinen> No. With the addition of invulnerable units, there is no longer a problem of units having insane HP and combat simulation eating too much memory.
20160906 03:18:33< JyrkiVesterinen> I consider the problem solved.
20160906 03:18:45< celmin> So you don't think it's worth it anymore?
20160906 03:18:50< JyrkiVesterinen> Exactly.
20160906 03:19:57< celmin> I guess the idea is that the only reason for insane HP was debugging.
20160906 03:20:32< celmin> Is "redo" really the last hotkey on the list? This somehow feels incorrect.
20160906 03:20:42-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160906 03:21:23< JyrkiVesterinen> celmin: Yes, that's indeed what I am thinking.
20160906 03:22:04< celmin> If they're in native order, it should be "show Lua console" right?
20160906 03:22:10< JyrkiVesterinen> Nore complained about performance problems with an unit that had a million hitpoints. He had increased the HP for debugging purposes.
20160906 03:22:52< JyrkiVesterinen> I think *that* kind of HP is/was only seen in debugging situations.
20160906 03:23:10 * celmin wonders how high HP gets in LotI.
20160906 03:23:20< JyrkiVesterinen> If the HP is at least somewhat reasonable, memory usage isn't going to get completely out of control.
20160906 03:23:41< JyrkiVesterinen> 1000 HP vs 1000 HP, both have slow: 32 MB
20160906 03:23:52< tad_> ouch
20160906 03:24:22< JyrkiVesterinen> It's still not in the gigabyte range that you'd get if it was 1M HP vs 1K HP.
20160906 03:25:10< celmin> Does both having slow make a difference there?
20160906 03:25:16< vultraz> celmin: what?
20160906 03:25:17-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160906 03:25:28< JyrkiVesterinen> Yes. If either unit has slow, it doubles memory usage.
20160906 03:25:34< JyrkiVesterinen> Both having slow quadruples it.
20160906 03:25:37< vultraz> Show Lua Console
20160906 03:25:52< celmin> Okay, so there's still something very wrong in my listbox. :/
20160906 03:26:18< celmin> I thought the array was indexed by resultant HP.
20160906 03:26:39< JyrkiVesterinen> There are separate arrays for the different slow permutations.
20160906 03:27:01< JyrkiVesterinen> The worst case if four arrays: "neither slowed", "A slowed", "B slowed", "both slowed".
20160906 03:27:08< JyrkiVesterinen> *is
20160906 03:27:51< tad_> What are you doing? Simulating all possible outcomes?
20160906 03:28:00< celmin> That's what it does, yes.
20160906 03:28:52< tad_> Are the weapon damages in line with the HP? Like are we talking 1K WD vs 1K HP? If not, just use a heuristic.
20160906 03:29:42< JyrkiVesterinen> No, the algorithm allocates space for all HP values from zero to maximum HP.
20160906 03:29:54< tad_> For example, if we're talking about 10WD vs 1000HP just divide both by 10. The statistical error would average out and nobody would be able to prove the error because it's going to be so damned small.
20160906 03:29:56-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 03:30:06< celmin> What's WD?
20160906 03:30:11< celmin> Oh.
20160906 03:30:13< celmin> You said it already.
20160906 03:30:13< tad_> Damage per hit
20160906 03:30:31< JyrkiVesterinen> This is existing code. I'd like to keep it intact unless we really need to optimize.
20160906 03:31:01< JyrkiVesterinen> The 32 MB case above it pretty much an absolute worst-case even for UMC.
20160906 03:31:10< JyrkiVesterinen> I don't consider it unacceptable at all.
20160906 03:31:24< JyrkiVesterinen> Not worth optimizing further in my opinion.
20160906 03:31:32< tad_> Sounds like "really need to optimize" to me if we're talking a 1000x1000 matrix to get a precise answer which will vary by what? 0.001% from the avrage?
20160906 03:32:43< JyrkiVesterinen> Well, yes, the code does things in a bit stupid ways.
20160906 03:33:02< tad_> It sounds like a lot of work to handle the 1-in-100,000 chance that it'll do something outside the average.
20160906 03:33:15< JyrkiVesterinen> But it's very tricky code, and optimizations carry a high risk of accidentally introducing regressions.
20160906 03:33:46 * tad_ nods.
20160906 03:33:47< JyrkiVesterinen> You can feel free to try, and send a PR. I can review and optionally merge it.
20160906 03:33:56< JyrkiVesterinen> But I'm not going to do it myself.
20160906 03:36:06< tad_> I'd need to learn a lot more about how the engine works to even attempt a PR. And, then, I'd probably get side-tracked by some other lameness.
20160906 03:36:47< JyrkiVesterinen> Heh, myself I'm quite good at picking up unfamiliar codebases.
20160906 03:37:12< JyrkiVesterinen> I hadn't even seen the combat simulation code until I started implementing the Monte Carlo simulation mode.
20160906 03:37:31< JyrkiVesterinen> And now I'm essentially the combat simulation expert here. :)
20160906 03:38:06< tad_> I was going to say the Monte Carlo method would be a good way to handle it. Like "If the HP of any unit is over N, always use Monte Carlo"
20160906 03:39:05< JyrkiVesterinen> The Monte Carlo method doesn't do anything to memory usage.
20160906 03:39:24< vultraz> 32mb of memory usage?
20160906 03:39:27< JyrkiVesterinen> It still uses a similar matrix to store the simulation results.
20160906 03:39:31< vultraz> how is that a lot.
20160906 03:39:43< JyrkiVesterinen> Yes, exactly.
20160906 03:40:11< celmin> It is a lot, but relative to typical computer RAM these days, it's not a big dent.
20160906 03:40:29< tad_> Not by itself.
20160906 03:40:32< celmin> Still, it's a lot.
20160906 03:41:12< vultraz> "not a big"
20160906 03:41:18< vultraz> it's nothing :|
20160906 03:41:50-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 03:43:14< celmin> Seems like theres only 6 items vanishing off the bottom of the listbox.
20160906 03:43:15< tad_> My point is does it really need to simulate all possible cases? If you scale by order-of-magnitude a 100x100 table would be about the same size as a 10000x10000 and the statistical error would be to small. You'd have to collect data from over 1000 replays of the battle to get a meaninful dataset and prove the error.
20160906 03:43:19< celmin> ^there's
20160906 03:43:58< JyrkiVesterinen> No, of course it doesn't need to simulate all possibilities.
20160906 03:44:19< JyrkiVesterinen> But simulating them all is the easiest option, and more important, what the code currently does.
20160906 03:44:53< celmin> So I've set it so that the "total number of items" in the scrollbar container is equal to the number of rows in the listbox.
20160906 03:45:11< celmin> To get the number of items visible, I do the following:
20160906 03:45:32< vultraz> JyrkiVesterinen: do you have room in your todo list for something?
20160906 03:45:48< JyrkiVesterinen> Yes, I do. There are only a couple of items there.
20160906 03:46:04< celmin> 1. Divide total height of the listbox interior by the number of items to get an average row height.
20160906 03:47:03< celmin> 2. Divide the height of the visible area by the average row height to estimate the number of visible rows.
20160906 03:47:09< vultraz> JyrkiVesterinen: https://gna.org/bugs/index.php?22176 AFAIK this is still an issue. Aginor said it's because tooltips are displayed in popup 'windows' and as such set the is_in_dialog flag. Need some way to not set is_in_dialog for tooltips and for dropdown menus, but I can't figure out a good way.
20160906 03:47:14< celmin> 3. Increment this number if it does not divide evenlt.
20160906 03:47:16< celmin> ^evenly
20160906 03:47:41< celmin> The result is returned as the number of visible items in the scrollbar container.
20160906 03:47:50< celmin> Can anyone see anything wrong with this approach?
20160906 03:48:20< celmin> vultraz: Sounds like you need an RAII approach to is_in_dialog.
20160906 03:49:55< tad_> celmin: it depends on even distribution of error. if row heights vary randomly you can expect a significant number of times when the bottom row (or rows) will get cut off because you had bad luck and the upper rows presently viewed are all above-average.
20160906 03:50:44< vultraz> indeed
20160906 03:50:49< celmin> Hmm, that does seem like a valid concern, though the rows are all the same height in my specific test and there's still several being cut off.
20160906 03:51:11< JyrkiVesterinen> Yes, I think such an approach would indeed work.
20160906 03:51:11< tad_> celmin: would it be possible to use max(height(all_rows)) and display padding for all shorter rows?
20160906 03:51:36< vultraz> in gui1, somehow the list always displayed full rows
20160906 03:51:38< tad_> If you are sure all rows are the same height, no need to average. height(row[0]) will do.
20160906 03:51:43< celmin> Instead of average row height?
20160906 03:51:49< celmin> I could do that, I think.
20160906 03:51:55< vultraz> rows may not be the same height
20160906 03:51:58< vultraz> just saying
20160906 03:52:00< JyrkiVesterinen> It reminds me of a physics-based game I have worked on. It needs a way to turn off physics when the game is paused, for example.
20160906 03:52:32< JyrkiVesterinen> It was implemented with so-called physics locks. To disable physics, the pause menu or dialog or whatever needed to grab a physics locks.
20160906 03:52:45< JyrkiVesterinen> As long as at least one physics lock existed, physics were disabled.
20160906 03:52:47< tad_> celmin: and watch for when integer rounding hits. best to do (window + max - 1) / num than to do (window / num) and round up.
20160906 03:53:12< celmin> tad_: Rounding at which stage, specifically?
20160906 03:53:29< celmin> At step 1?
20160906 03:53:40< celmin> I did account for rounding at step 2 by incrementing the result...
20160906 03:53:52< tad_> Any divide. Try to do it as the last step.
20160906 03:54:01< vultraz> hm.. this is odd
20160906 03:54:06-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 03:54:08< celmin> Well, I'll try the max-height instead of average-height way...
20160906 03:54:15< vultraz> the problems I were having earlier go away if i make them happen every time :/
20160906 03:54:36< vultraz> im not.. sure why
20160906 03:54:49< celmin> Though, if I do that, I feel like the "total number of items" should be adjusted.
20160906 03:55:01< vultraz> that is, if I remove the if(active || !w.get_value_bool()) return;
20160906 03:55:02< vultraz> bit
20160906 03:55:04 * vultraz ponders
20160906 03:55:35< vultraz> so if you're enabling a widget...
20160906 03:55:41< vultraz> dont deselect...
20160906 03:55:53< vultraz> but if you're enabling, it won't be selected anyway...
20160906 03:56:28< vultraz> also, if the widget was NOT selected...
20160906 03:57:07< vultraz> yeah I can't follow this logic
20160906 03:57:10< vultraz> I'm missing something
20160906 03:57:46< vultraz> set_active doesn't change selected states afaik..
20160906 03:59:45< vultraz> let's walk through
20160906 03:59:48< vultraz> male toggle
20160906 03:59:54< vultraz> male is not available, active is false
20160906 04:00:01< vultraz> it calls set_active(false)
20160906 04:00:07< vultraz> set_value_bool(false)
20160906 04:00:25< vultraz> then loops through all widgets, sees the first is not active, and selects the second
20160906 04:00:37< celmin> set_active shouldn't change selected state - it's perfectly valid for a checkbox/radiobutton to be both selected and invalid.
20160906 04:00:42< celmin> ^selected and disabled
20160906 04:00:45< vultraz> right
20160906 04:01:04< vultraz> now, let is look at it with the logic check..
20160906 04:01:21< vultraz> set_active(false)
20160906 04:01:41< vultraz> since active is false, that's it
20160906 04:01:44< vultraz> now, female toggle
20160906 04:01:49< vultraz> female is available
20160906 04:01:55< vultraz> set_active(true)
20160906 04:02:16< vultraz> if(true || !get_value_bool()}
20160906 04:02:30< vultraz> get value bool would be false
20160906 04:02:38< mattsc> tad_, celmin: last thing I am doing tonight.  In my current version of getting the crash (which is yet again slightly different), I add some debug output afetr this line:
20160906 04:02:41< mattsc> https://github.com/wesnoth/wesnoth/blob/master/src/ai/manager.cpp#L169
20160906 04:02:49< vultraz> !fase == true
20160906 04:02:51< vultraz> proceeds
20160906 04:02:57< mattsc> Doing that, I get this: http://pastebin.com/5zZ3FL6f
20160906 04:02:58< vultraz> deselects the item...
20160906 04:03:10< tad_> celmin: On the [ai] issues I'm seeing. I'm getting more data indicating it's uninitialized data. And I'm feeling like I'm wasting my time because I'm having a hard time following the code. So I'm going to step away from it and get back to someplace I can make progress .. code reading DM and updating my PR so I can move on to other campaigns.
20160906 04:03:12< vultraz> ah!
20160906 04:03:19< vultraz> yes, here's the logic fallacy 
20160906 04:03:34< vultraz> ok, well.
20160906 04:03:49< vultraz> firstly, we want this function to independently handle reselection
20160906 04:03:51< celmin> tad_: So you think it's uninitialized rather than corrupted?
20160906 04:03:53< vultraz> not subsequent calls
20160906 04:04:02< mattsc> Which has me wondering why there are only 4 aspects in it.  Shouldn’t this not only contain the ones that are modified, but also those that should be there by default?
20160906 04:04:05< vultraz> so we should only check ... the selected statet
20160906 04:04:29< mattsc> which sounds somewhat similar to what tad_ just wrote ...
20160906 04:04:49< vultraz> let's see again
20160906 04:04:51< mattsc> celmin: ^
20160906 04:05:11< vultraz> male is selected
20160906 04:05:16< vultraz> we select a female-only unit
20160906 04:05:19< vultraz> active is false
20160906 04:05:25< vultraz> set_active(false)
20160906 04:05:27< tad_> celmin, mattsc In my repro-steps if I allow a recruit prior to Hylas appearing all issues disappear. Seems like a recruit-cycle before modify_side ai solves all ills.
20160906 04:05:29< vultraz> get_value_bool is true
20160906 04:05:32< vultraz> ok
20160906 04:05:42< mattsc> ah, no, wait, I might have screwed up something ...
20160906 04:06:02< tad_> mattsc: Your highlited line is where I got to and said "What, it's recursive?" and my mind boggles.
20160906 04:06:03< celmin> mattsc: That seems like what I'd expect from outputting cfg.
20160906 04:06:17< celmin> What's recursive?
20160906 04:06:26< mattsc> celmin: yes; I was trying to output cfg_
20160906 04:06:34< vultraz> wait
20160906 04:06:39< vultraz> ok, now it's back to failing...
20160906 04:06:45< vultraz> but further on
20160906 04:06:47< vultraz> let's see
20160906 04:07:08< vultraz> interesting
20160906 04:07:08< tad_> Like mattsc, I need to get off for the night ...
20160906 04:07:11< vultraz> it worked, then it didn't.
20160906 04:07:14< vultraz> same session :|
20160906 04:07:20-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160906 04:07:29< celmin> From what I understand, shouldn't it be taking the other branch?
20160906 04:07:48< celmin> The AI context has already been initialized, I thought.
20160906 04:08:56-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 04:09:00< mattsc> Ooo, look at that!
20160906 04:09:25< mattsc> celmin: may an [aspect] tag contain two [default] tags?
20160906 04:09:53< celmin> I don't think it causes problems. If I recall correctly, they'll be merged when the AI is initialized.
20160906 04:10:30< mattsc> http://pastebin.com/mAjUBT9H  (same place in the code, but part of cfg_ this time)
20160906 04:11:02< celmin> Okay, that's odd.
20160906 04:11:42< celmin> Not only are there two [default], but they also have different values.
20160906 04:11:50< mattsc> Also: http://pastebin.com/Ag45cKBi  (look at the name of the first default tag)
20160906 04:11:53< mattsc> yes
20160906 04:12:09-!- celmin [~celticmin@unaffiliated/celticminstrel] has left #wesnoth-dev []
20160906 04:12:43< mattsc> celticminstrel: still here?
20160906 04:12:58< celticminstrel> Whoa what where did that come from.
20160906 04:13:14 * celticminstrel killed the other client because it stopped responding.
20160906 04:13:51< mattsc> well, it’s either l.169 or 170 in ai/manager.cpp causing this.
20160906 04:14:05< mattsc> sorry, 168 or 169
20160906 04:14:14< celticminstrel> I was about to say.
20160906 04:14:44< mattsc> celticminstrel: anyways, I’m really really off now.  But maybe this is a starting point for you to look into?
20160906 04:14:48< celticminstrel> It's difficult for me to debug that part of the code, since the debugger refuses to acknowledge that certain stack frames are part of Wesnoth.
20160906 04:14:51< celticminstrel> But, maybe.
20160906 04:15:20< mattsc> I’ll check the logs tomorrow and pick back up here if needed/desired/useful.
20160906 04:15:24< celticminstrel> 'kay
20160906 04:15:30-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160906 04:15:40< celticminstrel> Given what I'm in the middle of, I'm not sure I'll get to it by tomorrow, but...
20160906 04:15:48< celticminstrel> (Plus it's midnight, so I might sleep soon.)
20160906 04:15:50< mattsc> okay, no worries
20160906 04:15:57< mattsc> ttyl
20160906 04:17:57< celmin> Ooh, average row height was 31, but max row height is 48.
20160906 04:19:42-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160906 04:20:09< celmin> Hmm, it still cuts off at the same place though...
20160906 04:20:14-!- Kwandulin [~Miranda@p200300760F42410C30AEED6D88269513.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160906 04:28:16-!- JyrkiVesterinen [~JyrkiVest@87-100-145-177.bb.dnainternet.fi] has quit [Quit: .]
20160906 04:33:09-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160906 04:33:10-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160906 04:37:20-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160906 04:48:59-!- irker526 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160906 04:48:59< irker526> wesnoth: Charles Dang wesnoth:master 5d6fe12ca3ce / src/gui/widgets/group.hpp: Refactored tgroup to use a map https://github.com/wesnoth/wesnoth/commit/5d6fe12ca3ce4742a903d7baff4ac02b93bb1e42
20160906 04:49:00< irker526> wesnoth: Charles Dang wesnoth:master 41b254da317f / src/units/types.hpp: Unit Type: implement helper to get whether a type has a specific gender variatio https://github.com/wesnoth/wesnoth/commit/41b254da317f1122ff280589fdd96b7048f5fa4a
20160906 04:49:01< irker526> wesnoth: Charles Dang wesnoth:master e6b0d1e84116 / src/gui/ (dialogs/unit_create.cpp widgets/group.hpp): Unit Create: don't show invalid gender options for the selected type https://github.com/wesnoth/wesnoth/commit/e6b0d1e84116fc40228ba583094e5f4e12ffc839
20160906 04:49:03< irker526> wesnoth: Charles Dang wesnoth:master 9918e0e3e8d9 / src/gui/dialogs/multiplayer/faction_select.cpp: Faction Select: made use of tgroup::set_member_active https://github.com/wesnoth/wesnoth/commit/9918e0e3e8d97c7c7eb3cc8bb7b0fb4176184087
20160906 04:49:21< vultraz> I just commented out that check in set_member_active
20160906 04:49:28< vultraz> I just couldn't get it to work otherwise
20160906 04:54:07< celticminstrel> I will likely make use of has_gender_variation in the unit types iterator.
20160906 04:54:23< vultraz> good, good
20160906 04:54:57< celticminstrel> I need to decide: 1) Whether male/female should be first or last in the iteration, and 2) whether to include base in the iteration.
20160906 04:55:19< vultraz> male first, of course 
20160906 04:55:22< celticminstrel> (base is such that ut.variations.base == ut)
20160906 04:55:42< celticminstrel> (It's there for internal use, but is visible to the Lua as well.)
20160906 04:56:08< celticminstrel> (Actually, come to think of it, you can probably assign to it...)
20160906 04:56:28< celticminstrel> (Maybe I should make it a userdata instead of a table. Then I can just conceal base.)
20160906 04:56:44< celticminstrel> Thoughts?
20160906 04:56:59< vultraz> eh?
20160906 04:57:12< celticminstrel> I'm talking about iterating over variations.
20160906 04:57:26< celticminstrel> Currently it only covers [variation] ones, not male/female.
20160906 04:57:39< celticminstrel> Also, ut.variations.base exists but is not included in iteration.
20160906 04:58:47< celticminstrel> I think you could actually assign base to be a different unit type, and the game would happily make the table of variations point to it instead; or assign nil, and cause the table to point to the full list of unit types. That seems like undesirable behaviour though.
20160906 04:59:48< vultraz> I see
20160906 05:08:57< celticminstrel> Your faction select does offer random gender, right.
20160906 05:09:12< vultraz> yes
20160906 05:09:18< vultraz> the flg manage implements it
20160906 05:16:50< irker526> wesnoth: Charles Dang wesnoth:master f4ba176e1e38 / src/gui/widgets/group.hpp: Added a single-member group getter https://github.com/wesnoth/wesnoth/commit/f4ba176e1e38b275af5ec41928fd1435c0cc8895
20160906 05:16:54< vultraz> might be useful for someone
20160906 05:16:58< vultraz> little cleaner too
20160906 05:17:57< vultraz> group.member<type>(value).stuff instead of dynamic_cast<type&>(group.members()[value].stuff
20160906 05:21:54-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160906 05:22:52-!- travis-ci [~travis-ci@ec2-54-204-255-172.compute-1.amazonaws.com] has joined #wesnoth-dev
20160906 05:22:53< travis-ci> wesnoth/wesnoth#10722 (master - 9918e0e : Charles Dang): The build was broken.
20160906 05:22:53< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157788391
20160906 05:22:53-!- travis-ci [~travis-ci@ec2-54-204-255-172.compute-1.amazonaws.com] has left #wesnoth-dev []
20160906 05:23:49< vultraz> so... I need to drop the trailing const, I guess..
20160906 05:31:47-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 05:41:15-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160906 05:46:17-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160906 05:53:03< mattsc> tad_, celmin: I have figured out what is going on with the [modify_side][ai] problems tad_ has found.  I left a comment explaining it with tad_’s Issue 28 on github.
20160906 05:53:12-!- travis-ci [~travis-ci@ec2-54-204-255-172.compute-1.amazonaws.com] has joined #wesnoth-dev
20160906 05:53:13< travis-ci> wesnoth/wesnoth#10723 (master - f4ba176 : Charles Dang): The build was broken.
20160906 05:53:13< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157791434
20160906 05:53:13-!- travis-ci [~travis-ci@ec2-54-204-255-172.compute-1.amazonaws.com] has left #wesnoth-dev []
20160906 05:57:58< JyrkiVesterinen> vultraz: Odd. I can't see any reason why GCC would ignore that const qualifier.
20160906 06:18:09-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160906 06:31:03-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160906 07:00:36-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160906 07:15:51-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160906 07:34:25-!- boucman_work [~boucman@246.105.204.77.rev.sfr.net] has joined #wesnoth-dev
20160906 07:42:58-!- Kwandulin [~Miranda@p200300760F42410C30AEED6D88269513.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20160906 08:12:15-!- Bonobo [~Bonobo@2001:44b8:254:3200:69a2:d1fa:e52f:cc69] has joined #wesnoth-dev
20160906 08:16:58-!- irker526 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160906 08:35:08-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160906 08:56:27-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160906 09:13:27-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20160906 09:24:49-!- Kwandulin [~Miranda@p200300760F42410CD9ED0B2224C928EB.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160906 09:27:13-!- boucman_work [~boucman@246.105.204.77.rev.sfr.net] has quit [Ping timeout: 244 seconds]
20160906 09:45:35-!- boucman_work [~boucman@246.105.204.77.rev.sfr.net] has joined #wesnoth-dev
20160906 10:34:06-!- Kwandulin [~Miranda@p200300760F42410CD9ED0B2224C928EB.dip0.t-ipconnect.de] has quit [Read error: No route to host]
20160906 10:52:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160906 11:18:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160906 11:25:50< vultraz> blah
20160906 11:26:15< vultraz> so it seems notify_modified is not supposed to be a notification of a widget's modification
20160906 11:26:32< vultraz> it's specifically a MODIFIED event
20160906 11:26:41< vultraz> which is why only some widgets like the scrollbar use it
20160906 11:27:06< vultraz> for something like the toggle button, it uses LEFT_BUTTON_CLICK
20160906 11:27:39< vultraz> explains why I can't use my status label helper with toggle buttons :/
20160906 11:29:43< vultraz> however, toggle_buttons don't actually hook custom callbacks into LEFT_BUTTON_CLICK
20160906 11:30:30< vultraz> it uses a custom callback function bound to the widget object
20160906 11:30:54< vultraz> making it difficult to generalize this code :|
20160906 11:32:57< vultraz> i could add a second template and use connect_signal directly
20160906 11:33:28< vultraz> except for the fact that using connect signal in this context gives compiler errors :|
20160906 11:34:36< vultraz> one would think NOTIFY_MODIFIED should be implemented for all widgets
20160906 11:35:00< vultraz> as a generic 'something changed' hook
20160906 11:38:40< vultraz> hm
20160906 11:39:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160906 11:39:50< vultraz> yeah, whatever's with this usage, connect_signal just does not like
20160906 11:40:33< vultraz> at least it stops one of the errors if I cast it to twidget.
20160906 11:41:02< vultraz> still, no point trying to template-ize the event type if the only thing that works is the wrappers
20160906 11:41:23< vultraz> plus I don't know the std::enbale_if template magic such a thing would require anyway :/
20160906 11:42:39< vultraz> one would think you could just pass the widget to an overload and then to the type-specific event binder but the dispatcher doesn't like it when I do that, for some reason
20160906 11:43:05< vultraz> blah
20160906 11:44:01< vultraz> I wonder if the event chain will blow up if I fire a NOTIFY_MODIFIED event from a LEFT_BUTTON_CLICK event
20160906 11:44:25< vultraz> let us see
20160906 11:45:01-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160906 11:46:32< vultraz> ... huh
20160906 11:46:37< vultraz> that does work
20160906 11:46:41< vultraz> iiinnttereesstiinnggg
20160906 11:47:09< vultraz> should this become standard behavior, though?
20160906 11:47:44< vultraz> ie, should the standard behavior of each widget fire a NOTIFY_MODIFIED event
20160906 11:48:15< vultraz> I shall ask celticminstrel
20160906 11:50:21-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has joined #wesnoth-dev
20160906 11:50:24-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160906 12:19:42-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has quit [Quit: Leaving]
20160906 12:32:02-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160906 12:46:22-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160906 12:55:29-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160906 12:57:17-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 12:59:12-!- Kwandulin [~Miranda@p200300760F42410CC4BB813C3D7A35F1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160906 13:05:53-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160906 13:06:18-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160906 13:08:09< mattsc> celticminstrel: good morning; did you see my message on what’s going on with tad_’s [modify_side][ai] issue?
20160906 13:10:07-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20160906 13:10:07-!- wedge010 is now known as wedge009
20160906 13:12:44< celticminstrel> Probably not.
20160906 13:14:05< mattsc> celticminstrel: in a nutshell, config::merge_with does not work correctly in this case, whith the two configs being merged having different numbers of [aspect] tags.
20160906 13:14:18< mattsc> I left more information in a comment in tad_’s issue on github
20160906 13:22:19-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160906 13:23:07-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160906 13:29:19-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 252 seconds]
20160906 13:42:44-!- gfgtdf [~chatzilla@x4e36a54d.dyn.telefonica.de] has joined #wesnoth-dev
20160906 13:48:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160906 14:00:41< mattsc> Hmm, there’s a fundamental flaw in the attack rating of the AI, which causes, among other things, the bug that units with max_moves=0 do not attack.
20160906 14:01:12< mattsc> It also causes units on terrain from which they cannot move away not to attack.
20160906 14:01:27< mattsc> I know what’s the reason for this, I am not certain how best to fix it.
20160906 14:03:29< celticminstrel> What's the reason?
20160906 14:04:03< mattsc> sorry, being distracted by trying out something else ...
20160906 14:04:21< mattsc> There’s a parameter called ‘support’ in the attack rating.
20160906 14:05:08< mattsc> It’s essentially the power (in whatever units, doesn’t matter for the argument) that the AI can bring to the attack hex.
20160906 14:05:17-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160906 14:05:37< mattsc> It calculates that from the movemap of the AI units.
20160906 14:05:59< mattsc> However, units that cannot move anywhere are not included in that movemap, not even on the hex they are on)
20160906 14:06:44< mattsc> Thus, if no other units can get there, support=0, which is multiplied to the attack rating which needs to be >0 for an attack to be considered.
20160906 14:06:45< celticminstrel> So one possible solution would be to include them in the movemap, though since I don't know exactly what the movemap is, I'm not certain that actually makes sense.
20160906 14:07:20< mattsc> I’ve been advocating that for a long time for different reasons, but I think it is not possible in practice.
20160906 14:07:45< mattsc> movemaps are used all over the place in Wesnoth, and I am sure doing so would cause all kinds of other problems elsewhere.
20160906 14:08:14< mattsc> So, as a result, if there’s a single unit and it can move somewhere, its own power gets added to ‘support’.
20160906 14:08:32< mattsc> However, if it cannot move, this does not happen and support=0.
20160906 14:08:53< mattsc> That’s what I mean with fundamental flaw; or maybe inconsistency is the better word.
20160906 14:09:59< celticminstrel> Hmm, where would I look for the movemap...
20160906 14:10:11< zookeeper> and it wouldn't be easy to hack in an extra argument or work around it in some other way?
20160906 14:10:45< celticminstrel> src/ai/contexts.cpp has a lot of references...
20160906 14:12:00-!- louis94 [~~louis94@91.178.242.33] has joined #wesnoth-dev
20160906 14:12:03-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 14:12:26< celticminstrel> Okay, so the movemap is a multimap<map_location,map_location>
20160906 14:12:40< celticminstrel> So presumably all possible src,dst pairs.
20160906 14:12:47< mattsc> celticminstrel: calculate_possible_moves in contexts.cpp
20160906 14:13:30< mattsc> zookeeper: there are a bunch of different ways to do this, I just don’t know which one is best ...
20160906 14:13:35-!- Kwandulin [~Miranda@p200300760F42410CC4BB813C3D7A35F1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160906 14:13:53< celticminstrel> Lines 376..9
20160906 14:14:05< mattsc> zookeeper, celticminstrel: just as an example, the eyestalk in TSG S7a does not attack if you remove surrounding units of its side.
20160906 14:14:28< mattsc> I actually think I have come up with my preferred solution ...
20160906 14:14:42< mattsc> It’s super simple and I think it will do a decent job.
20160906 14:14:48< celticminstrel> Units with no movement left are considered incapacitated.
20160906 14:14:54< mattsc> Give me a moment.
20160906 14:15:05< mattsc> celticminstrel: yes
20160906 14:15:06< celticminstrel> Which sort of make sense, since it's the movement map.
20160906 14:15:20< mattsc> celticminstrel: I’m not saying it doesn’t make sense.
20160906 14:15:28< celticminstrel> I know
20160906 14:15:32< mattsc> I’m just saying that it causes problems in certain circumstances.
20160906 14:15:37< mattsc> okay  :)
20160906 14:16:06< celticminstrel> #ifdef SUOKKO ...
20160906 14:16:40< celticminstrel> We should maybe do something about that. Either enable it or delete it.
20160906 14:17:25< mattsc> We should definitely not enable that.
20160906 14:17:33< celticminstrel> Oh?
20160906 14:17:36< mattsc> It could be deleted though.
20160906 14:17:44< celticminstrel> There are a total of four.
20160906 14:18:11< mattsc> I was not around at the time, but apparently suokko decided to change some things in the AI and things got quite screwed up.
20160906 14:18:32-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20160906 14:18:41< celticminstrel> Ah, I see.
20160906 14:19:34-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160906 14:19:36< zookeeper> not only in the AI as far as i know... :p
20160906 14:19:46< mattsc> My interpretation is that these things got left in as a nod to him in case he got back to fix things.
20160906 14:20:29< mattsc> celticminstrel: back to the “support bug”, there was a similar issue with units being entirely surrounded by enemies never attacking those enemies.
20160906 14:20:45< mattsc> For the same reason, since no AI units could come to them for support.
20160906 14:21:08< mattsc> I fixed that 3 years ago and I think I’m in favor of doing this in the same way.
20160906 14:21:14< mattsc> Let me find the line ...
20160906 14:21:59-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160906 14:22:18< mattsc> celticminstrel: https://github.com/wesnoth/wesnoth/blob/master/src/ai/default/attack.cpp#L313
20160906 14:22:50< mattsc> I suggest adding ‘support != 0’ to that conditional.
20160906 14:23:02< celticminstrel> if(leader_threat)?
20160906 14:23:28< celticminstrel> How was the problem with surrounded units not attacking solved?
20160906 14:23:31< mattsc> well, … and !is_surrounded etc.
20160906 14:23:42< celticminstrel> That is_surrounded flag I guess.
20160906 14:23:47< mattsc> yes
20160906 14:23:52-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 255 seconds]
20160906 14:24:00< celticminstrel> Would it work to change the is_surrounded flag to something more general?
20160906 14:24:30< celticminstrel> What would adding support != 0 to the leader_threat check do?
20160906 14:24:37< mattsc> Probably - but the problem is it would add additional overhead to pretty much every attack evaluation.
20160906 14:24:49< mattsc> it’s not a leader_threat check
20160906 14:25:12< celticminstrel> Oh wait, my line numbers changed from deleting suokko's stuff, I guess.
20160906 14:25:20< mattsc> It’s a check for under which conditions the attack rating should be multiplied by ‘support'
20160906 14:25:29< mattsc> Oh, I see.
20160906 14:25:34< mattsc> It’s this line:
20160906 14:25:37< celticminstrel> Ah, it's the !leader_threat
20160906 14:25:44< mattsc> if(!leader_threat && vulnerability*terrain_quality > 0.0 && !is_surrounded)
20160906 14:25:52< celticminstrel> Yeah, I found it with XCode's diff tool. 
20160906 14:26:07< mattsc> Ooo, if vulnerability is greater than the shocked smiley !
20160906 14:26:18< celticminstrel> XD
20160906 14:26:34< celticminstrel> My client doesn't convert that to shocked. Maybe because it's a perfectly valid number.
20160906 14:27:20< mattsc> I might just have the “show emoticons” preference enabled, don’t remember
20160906 14:27:30< celticminstrel> Yeah, okay, adding support != 0 to that makes sense.
20160906 14:27:31< mattsc> Well, anyway, I think just adding support != 0 is actually the perfect solution here.
20160906 14:27:35< celticminstrel> Can support be negative?
20160906 14:27:41< mattsc> No.
20160906 14:28:08< celticminstrel> It's a double, so it hypothetically could be, I guess.
20160906 14:28:14< celticminstrel> Hmmm...
20160906 14:28:17< mattsc> And the thing is, support should _always_ include the unit itself, at least, as can be seen from the case when the unit has MP.
20160906 14:28:40< mattsc> Well, it might be mathematically possible, but logically it’s not.
20160906 14:28:45< mattsc> I think.
20160906 14:29:47< mattsc> Not multiplying by ‘support’ changes the attack rating, of course, but in that case it is by necessity the only attack that is possible, so it does not get compared to anything else and it doesn’t matter.
20160906 14:30:12< celticminstrel> Do we have to worry about the possibility of it being something ridiculously small, like 0.000000000000000000000001?
20160906 14:30:17< mattsc> Okay, I’ll do that and do a bunch of tests, but I think this is the right solution.
20160906 14:30:37< mattsc> I don’t think so.
20160906 14:30:53< celticminstrel> Okay, in that case, testing != 0.0 seems fine to me.
20160906 14:32:28-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160906 14:33:44< mattsc> For example, in a grunt vs. grunt attack on flat, support is of the order 8.
20160906 14:33:57< celticminstrel> "of the order"?
20160906 14:34:09< celticminstrel> Does that mean like 0^8?
20160906 14:34:12< celticminstrel> 10^8
20160906 14:36:18< mattsc> No, I mean around support=8
20160906 14:36:25< celticminstrel> Okay.
20160906 14:36:53< mattsc> I just tested it on the eyestalk in TSG and it certainly works there.
20160906 14:37:16< mattsc> I’ll be offline for half an hour, then do a few more tests, and then commit this.
20160906 14:37:23< celticminstrel> Okay.
20160906 14:37:45< mattsc> Funny how you look at all kinds of things and in the end, the solution is super simple.
20160906 14:37:50< celticminstrel> I'll make sure not to commit anything unless I can finish this fast (which is unlikely).
20160906 14:38:19< celticminstrel> Though I might just give up on this and come back to it later. :/
20160906 14:38:23< mattsc> celticminstrel: don’t worry about me with that, it’s quick and easy to change/adapt.
20160906 14:38:38< mattsc> But let me know if you want me to wait until you’re done.
20160906 14:39:22-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160906 14:41:05< celticminstrel> I wonder if anyone could help me figure out how to get the dependencies for compiling with MSVC 2013.
20160906 14:41:15< celticminstrel> I should already have Boost, at least.
20160906 14:41:27< celticminstrel> I think it's 1.57 or so.
20160906 14:41:42< celticminstrel> SDL should be easy.
20160906 14:41:53< celticminstrel> Might've gotten that already, can't remember.
20160906 14:42:55< celticminstrel> Blargh. Maybe I should go back to the idea of making a custom listbox definition with no actual bar...
20160906 14:44:34-!- Bonobo [~Bonobo@2001:44b8:254:3200:69a2:d1fa:e52f:cc69] has quit [Quit: Leaving]
20160906 14:51:45< celticminstrel> Aginor: Should we change the fullscreen mode for 1.13.6 to allow arbitrary fullscreen resolutions? Some people have complained about that on the forums.
20160906 14:56:16< celticminstrel> Whoa, just updated my Windows repo and the diff overflowed the console backscroll.
20160906 14:56:35< celticminstrel> Just with the new/deleted files.
20160906 14:56:43< celticminstrel> s/diff/stat/
20160906 14:57:31-!- gfgtdf [~chatzilla@x4e36a54d.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160906 15:02:08-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160906 15:02:17-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160906 15:02:24 * celmin has a Lua thing to push, so if mattsc could wait for that, that would be great.
20160906 15:02:29< mattsc> celticminstrel: somethings in RL has come up that I need to take care off.  So please don’t wait for me.
20160906 15:02:49< mattsc> I might nto even be able to get back to this today.
20160906 15:03:03< celmin> Ah.
20160906 15:05:01-!- Kwandulin [~Miranda@p200300760F42410CC153FE2419E51D74.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160906 15:09:07< mattsc> celmin: do whatever you need/want to do, and I’ll pick up wherever when I have time to get back to Wesnoth.
20160906 15:13:34-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 15:23:30-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 15:24:32-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160906 15:31:59< celmin> …I think several hotkeys are erroneously identified as "available at titlescreen".
20160906 15:34:17< celmin> …and XCode suddenly crashed all of a sudden while searching.
20160906 15:40:08< celmin> Oh. I was wrong. I just accidentally hid it. X
20160906 15:40:10< celmin> XD
20160906 15:42:26-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 15:44:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160906 15:45:49-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160906 15:45:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160906 15:52:51-!- louis94 [~~louis94@91.178.242.33] has quit [Quit: Konversation terminated!]
20160906 15:53:57-!- louis94 [~~louis94@91.178.242.33] has joined #wesnoth-dev
20160906 15:58:40-!- boucman_work [~boucman@246.105.204.77.rev.sfr.net] has quit [Remote host closed the connection]
20160906 16:02:01-!- irker449 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160906 16:02:01< irker449> wesnoth: Celtic Minstrel wesnoth:master b7455d3bd43e / src/ai/default/ (aspect_attacks.cpp attack.cpp contexts.cpp): Remove suokko AI remnants https://github.com/wesnoth/wesnoth/commit/b7455d3bd43e4591daccbb1a7665f0d0f0cc188c
20160906 16:02:01< irker449> wesnoth: Celtic Minstrel wesnoth:master 91bd6ab6d09e / src/scripting/ (lua_unit_type.cpp lua_unit_type.hpp): Fix returning invalid unit types (bug #25041) https://github.com/wesnoth/wesnoth/commit/91bd6ab6d09e28048cb12018fea2f6f9c323762b
20160906 16:07:26-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160906 16:09:49-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160906 16:15:11< celmin> Given that we use the __ipairs metamethod, I wonder if updating to Lua 5.3 is even possible...
20160906 16:15:26-!- JyrkiVesterinen [~JyrkiVest@87-100-211-195.bb.dnainternet.fi] has joined #wesnoth-dev
20160906 16:18:41-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160906 16:19:48< tad_> celmin: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
20160906 16:19:54< celmin> Where?
20160906 16:20:14< tad_> In units.hpp and types.hpp
20160906 16:20:30< celmin> I need line numbers.
20160906 16:20:41< tad_> src/units/types.hpp:201
20160906 16:21:05< tad_> Ah.  3x all same line
20160906 16:21:37< tad_> More coming as make runs. All that line
20160906 16:24:01< celmin> I'm assuming zoom doesn't do anything at the titlescreen, right? What about screenshot and mute?
20160906 16:26:04< celmin> So I'm assuming the warning is because of the "const".
20160906 16:26:11< celmin> Removing that.
20160906 16:26:24< celmin> vultraz: For future reference, don't return things const unless they're a reference or pointer.
20160906 16:26:47< celmin> tad_: Was there something in units.hpp too, or was that the same as well?
20160906 16:27:03< tad_> same .. I misread the mess
20160906 16:37:42-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160906 16:37:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160906 16:38:07< celmin> aeth spotted!
20160906 16:40:05< aeth> striped aeths are worth more than spotted aeths
20160906 16:40:31< aeth> feathered aeths are the rarest, though
20160906 16:40:39< celmin> aeth: I was wondering if you have any opinions on a Lua API for animating units.
20160906 16:41:24< aeth> animations, AI, and random map generation are probably the only three Wesnoth things I haven't attempted at some point
20160906 16:41:34< celmin> I see.
20160906 16:44:18< irker449> wesnoth: Celtic Minstrel wesnoth:master 60c62bcabc0f / src/hotkey/hotkey_command.cpp: Remove several hotkeys from the titlescreen scope https://github.com/wesnoth/wesnoth/commit/60c62bcabc0f1db4799a9d21081748b8eb15eb56
20160906 16:44:20< irker449> wesnoth: Celtic Minstrel wesnoth:master 206096cc1e0d / src/units/types.hpp: Fix ignored qualifiers warning https://github.com/wesnoth/wesnoth/commit/206096cc1e0d732c31387b2d77c795773b0a2a00
20160906 16:44:54< celmin> aeth: So, no opinions?
20160906 16:45:04< aeth> no informed opinions, no
20160906 16:46:30< celmin> aeth: The C++ does them by creating a unit_animator object and adding animations to it, then running the animations. Does something similar to that sound good?
20160906 16:47:27< celmin> I get the impression that the animation is somehow asynchronous though...
20160906 16:48:10< celmin> Because it has things like 'start', 'pause', 'restart'...
20160906 16:48:27< celmin> 'wait_until', 'wait_for_end', etc...
20160906 16:51:49< celmin> aeth: Still no opinion, then?
20160906 16:53:01< JyrkiVesterinen> I have debugged the animation code. IIRC, it is synchronous.
20160906 16:53:20< aeth> I don't have an opinion in part because I'm not sure what needs to change in the C++ to get my map to run with passable CPU usage.
20160906 16:53:24< aeth> I'll have to look into that at some point
20160906 16:55:57< celmin> JyrkiVesterinen: So, perhaps it's the wait functions that to the actual work?
20160906 16:57:01< JyrkiVesterinen> I just had another look. The wait functions run the game loop (if we can call it that) until the animation ends.
20160906 16:57:26< celmin> BTW, do you know how I can get dependencies (other than Boost/SDL) for MSVC build?
20160906 16:57:28< JyrkiVesterinen> They wait 10 ms between each iteration, throttling animations to 100 FPS at most.
20160906 16:58:00< JyrkiVesterinen> I got the dependencies via this repository: https://github.com/aquileia/external
20160906 16:59:06< JyrkiVesterinen> The instructions I followed are here: https://wiki.wesnoth.org/CompilingWesnothOnWindows#Visual_Studio
20160906 16:59:55< aeth> Hmm, that's actually not good now that 4k 144 Hz monitors are just years away. Wesnoth won't be handled well at all on such screens
20160906 17:00:15< celmin> Ah, there were instructions.
20160906 17:00:23< celmin> I should have thought of that.
20160906 17:00:26< aeth> You won't get the 144 FPS (maybe not even 40) and everything will be tiny (1080p seems to be optimal)
20160906 17:00:30< JyrkiVesterinen> In a way, calling the animation wait functions is optional. However, if you don't call them, something needs to keep running the game loop.
20160906 17:00:44< JyrkiVesterinen> Otherwise animations would be extremely jerky.
20160906 17:02:05< JyrkiVesterinen> I have mentioned before that Wesnoth's rendering pipeline is highly abnormal, and this is a good example of that.
20160906 17:02:30< JyrkiVesterinen> Play_controller::play_slice() can be called from anywhere, and if it's not called, the game loop is completely stopped.
20160906 17:02:38< JyrkiVesterinen> Including rendering.
20160906 17:03:03< celmin> And there's even a convenient bundle, huh.
20160906 17:05:40-!- boucman_work [~boucman@2a02-8428-034f-f800-9e32-0c7c-b391-6223.rev.sfr.net] has joined #wesnoth-dev
20160906 17:08:03-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160906 17:08:03-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160906 17:09:51-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160906 17:10:28< celmin> The Debug build being unbearably slow sounds like a problem to me.
20160906 17:10:54< celmin> Though I haven't tested, maybe it'd be bearable on my… i7, if I recall correctly.
20160906 17:11:35< celmin> Do I actually need glib-2.0 and pkgconfig folders in lib/?
20160906 17:13:23< celmin> I don't like how the SDL includes are all in include/ rather than in include/sdl/ … oh well.
20160906 17:15:13< JyrkiVesterinen> I don't find the debug build unbearably slow at all. I mostly use them for testing.
20160906 17:15:40< JyrkiVesterinen> Although it may be that I just bear more slowness. I'm an extremely patient guy.
20160906 17:15:45< celmin> I seem to recall vultraz finding it unbearably slow possibly. Or something like that.
20160906 17:16:23< JyrkiVesterinen> For reference, I have got Core i5-4430 (four cores, 3,0 GHz).
20160906 17:17:14-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Ping timeout: 264 seconds]
20160906 17:17:25< JyrkiVesterinen> I don't know if the glib and pkgconfig directories are necessary. I haven't tried removing them.
20160906 17:17:52< celmin> Well, I guess I'll find out soon.
20160906 17:17:52-!- Kwandulin [~Miranda@p200300760F42410CC153FE2419E51D74.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160906 17:17:58< celmin> Because I didn't copy them.
20160906 17:18:19 * celmin put all the libs, dlls, and includes in the VC directory.
20160906 17:19:01< celmin> Seems like it can't find Boost or something.
20160906 17:19:33< celmin> Oh, because the project is set up to use local folders. Sigh.
20160906 17:19:37< celmin> Annoying.
20160906 17:24:28< celmin> What? external/ is supposed to be beside wesnoth/ ? :\
20160906 17:24:42< celmin> This seems ridiculous. :|
20160906 17:25:02-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has joined #wesnoth-dev
20160906 17:25:03< travis-ci> wesnoth/wesnoth#10725 (master - 206096c : Celtic Minstrel): The build has errored.
20160906 17:25:03< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157940535
20160906 17:25:03-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has left #wesnoth-dev []
20160906 17:25:45< celmin> ...
20160906 17:26:10-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160906 17:26:36< tad_> 20160906 12:22:27 error filesystem: Trying to open file with empty name. 20160906 12:22:27 error preprocessor: Could not open file  WML exception: User message: No default gui defined. Dev message: Condition 'default_gui != guis.end()' failed at /home/lundberg/wesnoth/src/gui/widgets/settings.cpp:531 in function 'load_settings'.
20160906 17:28:09< JyrkiVesterinen> celmin: Yes, indeed. That's where the external directory should be placed.
20160906 17:36:48-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160906 17:45:14-!- Nobun [~nobun@5.170.105.85] has joined #wesnoth-dev
20160906 17:46:47< Nobun> celmin, celticminstrel: first update progress on wmlxgettext update: I did some (uncommitted) changes on postring and WmlNode structure that should allow to manage plural forms
20160906 17:47:05< celmin> Ugh.
20160906 17:47:15< celmin> How is it an empty name?
20160906 17:48:21< Nobun> I introduced the class PoCommentedStringPL (or similar name) wich has value and ismultiline sub-parameters, and PoCommentedString, WmlNodeSentence are updated to support this new data
20160906 17:48:23< celmin> It's explicitly data/gui/_main.cfg
20160906 17:48:58< celmin> My VNC-to-Mac connection seems to be unresponsive.
20160906 17:49:40< Nobun> the work is going slow, since I have some tasks to perform... Still not new regexp introduced, even if I am thinking about how to design the Lua states for plural capture
20160906 17:50:02< Nobun> (I mean tasks in the real life)
20160906 17:50:42< Nobun> ... end of work progress report
20160906 17:50:54< celmin> Nobun: Okay.
20160906 17:51:20< celmin> I see, PL for plural. I didn't initially get that, somehow.
20160906 17:52:06-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 17:55:05< tad_> celmin: Tested and sure enough [unit] actually does mean "If on recall list, [recall] else [unit]"
20160906 17:55:12-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160906 17:55:21< celmin> I've put external/ there and it's still not finding Boost. :|
20160906 17:56:43< tad_> symlinks wrong?
20160906 17:56:51< Nobun> yes, celmin: however the name is temporary... it is a structure wich is used both in PoCommentedString and in WmlNodeSentence, so the name can be confusing... I will think about it in a later moment
20160906 17:57:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit []
20160906 17:58:37< celmin> Windows, so no symlinks.
20160906 17:59:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160906 17:59:21< Nobun> celmin: where do you have problems on finding boost?
20160906 17:59:29< celmin> MSVC
20160906 17:59:48< Nobun> hmm... using scons, i figure...
20160906 18:00:02< celmin> No, MSVC
20160906 18:00:13< Nobun> Ah... directly in MSVC you mean?
20160906 18:00:21< celmin> Yes
20160906 18:01:33< Nobun> Have you tried to use cmake with MSVC generator file? cmake should be able to create a compatible MSVC project wich should save the boost library you actually use
20160906 18:02:35< JyrkiVesterinen> First of all, are you sure that Boost is actually there?
20160906 18:03:03< JyrkiVesterinen> If you tried to get the libraries by cloning the external repo, note that you need to switch away from the master branch.
20160906 18:03:16< JyrkiVesterinen> To the VC12 branch to be precise.
20160906 18:03:51< celmin> ...
20160906 18:03:54< celmin> Wait.
20160906 18:04:04< celmin> Boost is there, but bimap specifically is missing???
20160906 18:05:02< celmin> Indeed, all the missing header errors now are bimap.
20160906 18:05:19< JyrkiVesterinen> Ah... Boost::bimap is indeed missing from aquileia's repository.
20160906 18:05:33< vultraz> celmin: what are your thoughts on making NOTIFY_MODIFIED events fire by more widgets?
20160906 18:05:34< JyrkiVesterinen> I haven't noticed because I have built Boost myself.
20160906 18:08:11< celmin> vultraz: Which ones?
20160906 18:08:19< vultraz> celmin: any one
20160906 18:08:30< celmin> Any seems a bit much maybe.
20160906 18:08:30< vultraz> as needed
20160906 18:08:36< vultraz> but right now, toggle buttons
20160906 18:08:43< celmin> Why?
20160906 18:09:01< vultraz> if you make them fire a MODIFIED event on their LEFT_CLICK event, I can use my status label helper on them
20160906 18:09:19< vultraz> without template magic to define a different event bind method
20160906 18:09:31< celmin> Is there a get_state_changed_callback()?
20160906 18:09:40< vultraz> what?
20160906 18:09:53< celmin> There's set_state_changed_callback(), right? Is there also a getter for it?
20160906 18:10:06< vultraz> no
20160906 18:10:06< celmin> Alternatively, does the setter return the previous value?
20160906 18:10:10< celmin> Okay.
20160906 18:10:30< vultraz> and no
20160906 18:10:35< celmin> I forget, is tselectable_ header-only?
20160906 18:10:55< vultraz> yes
20160906 18:11:43< celmin> So I think what I'd suggest is to remove everything about state changed callback from slider / toggle button / toggle panel / menu button, and implement it instead in tselectable_ using a NOTIFY_MODIFIED event.
20160906 18:12:00< celmin> Then the places that used to call the callback instead fire the event.
20160906 18:12:25< vultraz> I was thinking that, yes
20160906 18:12:39< vultraz> except it needs to be fired from the widgets themselves
20160906 18:12:45< vultraz> not the superclass
20160906 18:13:42< vultraz> much easier to do that than figure out std::enable_if
20160906 18:15:14< vultraz> so, you support this change?
20160906 18:18:53< celmin> Apparently 7zip cannot open tar files. :|
20160906 18:19:25< JyrkiVesterinen> It can. I have opened tar files with it.
20160906 18:19:37< vultraz> it can
20160906 18:19:41< vultraz> I have too
20160906 18:20:08< celmin> Then why isn't it working.
20160906 18:21:36-!- louis94 [~~louis94@91.178.242.33] has quit [Ping timeout: 276 seconds]
20160906 18:24:12< celmin> Maybe the tarfile is actually invalid.
20160906 18:25:45< vultraz> also, why can't we upgrade our lua?
20160906 18:28:31< celmin> Okay, I got the bimap headers by cloning the tag from the github repo.
20160906 18:28:50< vultraz> (seems the current release is up to 5.3.3)
20160906 18:29:01< celmin> vultraz: I got the impression that Lua 5.3 removed the __ipairs metamethod, which we're relying on in places.
20160906 18:30:29< celmin> Now zillions of warnings...
20160906 18:30:50< vultraz> wait, so we're stuck on 5.2 forever? D:
20160906 18:30:51< celmin> About truncated decorated names. :| Who cares.
20160906 18:31:29< celmin> vultraz: No, but if we were going to update, we'd need to make sure we're ready for it, either by not relying on anything that has been removed or by rolling a custom modification.
20160906 18:33:35< celmin> Also, they're from the Boost headers, so doubly don't care.
20160906 18:34:32< vultraz> what are you doing?
20160906 18:34:43< celmin> Building with MSVC.
20160906 18:35:03< vultraz> 15?
20160906 18:35:08< celmin> 12
20160906 18:35:17< celmin> It's also telling be to define _WIN32_WINNT.
20160906 18:35:19< celmin> ^me
20160906 18:35:37< celmin> JyrkiVesterinen: Do you not get tons of C4503 from Boost?
20160906 18:35:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160906 18:36:04-!- Nobun [~nobun@5.170.105.85] has quit [Ping timeout: 260 seconds]
20160906 18:36:04< vultraz> so it looks like __ipairs was indeed removed
20160906 18:36:15< JyrkiVesterinen> Was it the warning about type names being so long that they are truncated?
20160906 18:36:19< celmin> Yes.
20160906 18:36:22< JyrkiVesterinen> I do get tons of that warning.
20160906 18:36:32< vultraz> and it looks like it was for...performance reasons? cannot understand this thread
20160906 18:36:35< celmin> Any objections to suppressing it?
20160906 18:36:58< JyrkiVesterinen> No objections here.
20160906 18:37:12< celmin> vultraz: Worst case, if we want to move to Lua 5.3 but still use __ipairs, is that we need to reimplement ipairs().
20160906 18:37:23< vultraz> :|
20160906 18:37:36< vultraz> that is indeed the worst case
20160906 18:37:44< celmin> It's probably not that bad, honestly.
20160906 18:37:55< vultraz> I seem to recall there was some other reason we didn't update to 5.3...
20160906 18:38:11< celmin> I can't remember.
20160906 18:38:12< vultraz> Perhaps because I could never get the damn patch to apply.
20160906 18:38:33< celmin> There was the bitshift operators, which conflict with <<>> string syntax, I guess.
20160906 18:38:33< vultraz> I tried last October, but forgot the lua exception handling
20160906 18:38:41< vultraz> Then I tried again, but couldn't get it to work.
20160906 18:38:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160906 18:40:11< vultraz> ok, I'm adding a firing of NOTIFY_MODIFIED any place tselectable_ subclasses fired a callback_state_change_
20160906 18:41:30< vultraz> I'm not refactoring the usecases yet
20160906 18:42:25< vultraz> first, to refactor preferences 
20160906 18:43:04< vultraz> ya know, it's been months but these lines are still difficult for me to parse >_> 
20160906 18:43:07< vultraz> 				typedef void (*setter) (const std::string &, int);
20160906 18:43:09< vultraz> 				setter set_ptr = &preferences::set;
20160906 18:43:16< vultraz> I know what they do, but it's not very.. clear
20160906 18:43:35< JyrkiVesterinen> Maybe std::function would be more clear.
20160906 18:43:57< vultraz> likely, yes
20160906 18:44:23< celmin> So, it build, but crashed with a dll error.
20160906 18:44:47< JyrkiVesterinen> Does it complain that it doesn't find a symbol from a DLL?
20160906 18:45:02< celmin> Yes, I think that was it.
20160906 18:45:31< celmin> Need to rebuild now because I changed warning settings though.
20160906 18:45:32< JyrkiVesterinen> OK. The problem is that the game loads some DLLs from system-wide directories.
20160906 18:46:04< JyrkiVesterinen> Some other DLLs expect them to be the exact versions in aquileia's repository.
20160906 18:46:12< JyrkiVesterinen> You get that crash as a result.
20160906 18:46:35< JyrkiVesterinen> The fix is to move the external\dll directory to the first position in %PATH%.
20160906 18:46:43< celmin> Hmm.
20160906 18:46:59< celmin> I think I could probably just remove the zlib from external, though.
20160906 18:47:01-!- louis94 [~~louis94@91.178.242.33] has joined #wesnoth-dev
20160906 18:47:50< JyrkiVesterinen> For me, the problem was with SDL (loaded from exteral\dll) and FreeType (loaded from elsewhere).
20160906 18:48:40< celmin> Ugh.
20160906 18:48:47-!- esr [~esr@wesnoth/developer/esr] has quit [Quit: WeeChat 1.4]
20160906 18:53:19-!- Nobun [~nobun@5.170.107.24] has joined #wesnoth-dev
20160906 18:55:28< celmin> Ugh, why won't it disable. :(
20160906 18:55:37< celmin> Even though I added it in "Disable specific warnings"
20160906 18:58:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160906 18:59:02< celmin> Surely it's not because I skipped the liblua project.
20160906 19:03:18< JyrkiVesterinen> Did you disable the warnings in the configuration (Debug/Release) you're building?
20160906 19:03:34< celmin> Oh, that's a good question.
20160906 19:03:59< celmin> Yeah, I disabled them in release and am building debug.
20160906 19:05:56< celmin> Why are there so many configurations? o.o
20160906 19:06:05< celmin> What the heck is ReleaseDEBUG?
20160906 19:06:13< JyrkiVesterinen> I don't know. I only every build Debug and Release.
20160906 19:06:16< celmin> What's Debug_with_VLD?
20160906 19:06:21< celmin> Should I disable it on all configurations?
20160906 19:06:40< celmin> Or only Release and Debug?
20160906 19:06:42< JyrkiVesterinen> I guess ReleaseDEBUG is probably optimized build with debug symbols.
20160906 19:06:54< celmin> Or even, only Debug?
20160906 19:06:57< JyrkiVesterinen> All configurations would be best, I guess.
20160906 19:07:06< tad_> Either that or buld both at once
20160906 19:07:15< JyrkiVesterinen> But it doesn't matter much as long as it's disabled in Debug and Release.
20160906 19:07:17< vultraz> I can get a lambda working but not an std::function
20160906 19:07:19< vultraz> fine with me
20160906 19:08:04-!- Nobun [~nobun@5.170.107.24] has quit [Ping timeout: 240 seconds]
20160906 19:08:39< celmin> vultraz: What?
20160906 19:09:32< vultraz> you remember these such lines that were added to disambiguate the preferences::set overload:?
20160906 19:09:35< vultraz> 				typedef void (*setter) (const std::string &, const std::string &);
20160906 19:09:36< vultraz> 				setter set_ptr = &preferences::set;
20160906 19:10:43< vultraz> so I tried replacing that with this: std::function<void(const std::string&, const std::string&)>* set_ptr = &preferences::set; but it doesn't work.
20160906 19:10:48< celmin> Duh.
20160906 19:10:53< celmin> Because you added *
20160906 19:10:58< vultraz> I see
20160906 19:11:35< celmin> But don't do that anyway.
20160906 19:11:53< celmin> If you're going to use std::function, then just redefine the typedef.
20160906 19:11:58-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160906 19:12:12< vultraz> I could just do this, ftr
20160906 19:12:15< vultraz> 				const auto set_helper = [](const std::string& k, const std::string& v)->void {
20160906 19:12:16< vultraz> 					set(k, v);
20160906 19:12:18< vultraz> 				};
20160906 19:13:28< vultraz> which is preferable, honestly
20160906 19:13:40< celmin> I disagree.
20160906 19:13:51< celmin> It's pointlessly wrapping it in a lambda.
20160906 19:14:07-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 255 seconds]
20160906 19:14:07-!- wedge010 is now known as wedge009
20160906 19:14:23< celmin> There's no reason to add an extra level of redirection when it's not needed.
20160906 19:14:36< celmin> The setter functions already have exactly the right signature, so just use them as-is.
20160906 19:15:44< vultraz> hm?
20160906 19:16:21< celmin> Don't use a set_helper.
20160906 19:16:36-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20160906 19:16:48< celmin> What was the set_ptr / set_helper actually used for? Maybe you can just substitute all references to it with &preferences::set
20160906 19:16:54-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160906 19:17:00< vultraz> disambiguating the overload
20160906 19:17:31< vultraz> so for example...
20160906 19:17:58< celmin> I'm assuming wesnoth.sdf should not be in the repo?
20160906 19:18:00< vultraz> if we wanted the set(string, bool)...we'd create that set_ptr thing, then bind set_ptr...
20160906 19:18:03< vultraz> oh yeah
20160906 19:18:07< vultraz> I'll just pass a lambda directly
20160906 19:18:14< celmin> What?
20160906 19:18:34< celmin> Why are you using a lambda here? Don't use a lambda here.
20160906 19:18:45< celmin> If it's needed to disambiguate an overload, then just leave it as is.
20160906 19:19:13< celmin> Don't use a lambda to disambiguate an overload. That's just ridiculous.
20160906 19:20:04< vultraz> let's take the example using setup_single_toggle. that function took a void(bool) function as its setter. Before, it created a set_ptr to disambiguate the overload, and then passed std::bind(set_ptr, prefname, _1) to setup_single_toggle.
20160906 19:20:10< JyrkiVesterinen> celmin: wesnoth.sdf indeed shouldn't be in the repo.
20160906 19:20:22< vultraz> however, I can now just pass [pref_name](bool v)->void { set(pref_name, v); },
20160906 19:20:24< celmin> So I need to add it to ignores.
20160906 19:20:29< vultraz> get rid of bind
20160906 19:20:34< vultraz> and the set_ptr/set_helper
20160906 19:20:50< JyrkiVesterinen> wesnoth.sdf should already be in ignores.
20160906 19:21:12< vultraz> celmin: make sense.
20160906 19:21:30-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160906 19:21:50< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/master/.gitignore#L52
20160906 19:23:39< celmin> So then, why is git gui listing it?
20160906 19:23:56< JyrkiVesterinen> I don't know. I use command-line Git.
20160906 19:24:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160906 19:29:02< celmin> Ah, I see the problem. It's .opensdf, not .sdf, so if I remove the dot in the ignore line, it should work.
20160906 19:29:32< JyrkiVesterinen> wesnoth.opensdf exists only when the project is open.
20160906 19:29:47< celmin> I see. Still seems like something good to ignore though.
20160906 19:29:57< JyrkiVesterinen> For me, the fact that the file is *not* ignored acts as a useful reminder to close Visual Studio.
20160906 19:30:06< celmin> Really? Okay, fine, I'll leave it.
20160906 19:30:21< JyrkiVesterinen> (In particular, VS tends to write changes to project configuration on exit.)
20160906 19:30:45< celmin> It seems to write them immediately-ish for me.
20160906 19:30:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20160906 19:31:23< celmin> Still 133 warnings even with that one disabled...
20160906 19:31:27-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160906 19:31:31< JyrkiVesterinen> IIRC, it writes the changes on (1) compile, and (2) exit.
20160906 19:31:45-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160906 19:32:04< celmin> I see.
20160906 19:32:18< celmin> If I recall correctly though, you can also force it with Save All.
20160906 19:32:43< JyrkiVesterinen> I don't bother. I just exit VS when I'm preparing to commit.
20160906 19:33:00< celmin> I can't be bothered to do that. >_>
20160906 19:33:14-!- gfgtdf [~chatzilla@x4e36a54d.dyn.telefonica.de] has joined #wesnoth-dev
20160906 19:33:23< JyrkiVesterinen> celmin: One common warning according to my notes: 1>i:\battle for wesnoth\wesnoth\src\variable.hpp(199): warning C4510: 'vconfig::attribute_iterator::pointer_proxy' : default constructor could not be generated
20160906 19:33:33< celmin> Yeah, I noticed that too.
20160906 19:33:44< JyrkiVesterinen> Fixing that should bring the warning count down quite a bit.
20160906 19:34:48-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 19:35:25< gfgtdf> celmin: still looking for msvc libs ?
20160906 19:35:37< celmin> gfgtdf: Nope, found them now.
20160906 19:36:01-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160906 19:36:21< celmin> What's with this unreachable code warning...
20160906 19:36:52< gfgtdf> celmin: mostlikeley there is code after return or throw.
20160906 19:37:00< gfgtdf> celmin: where exactly do you get it ?
20160906 19:37:01< celmin> No, that's the thing.
20160906 19:37:24< celmin> game_initialization/multiplayer.cpp:837
20160906 19:38:11< JyrkiVesterinen> It's a loop that can only run once.
20160906 19:38:17< JyrkiVesterinen> Quite pointless.
20160906 19:38:27< JyrkiVesterinen> Note the unconditional break at the end.
20160906 19:38:38< celmin> Oh.
20160906 19:39:19< celmin> It seems like the break should be removed, but aside from that, how is there any unreachable code there?
20160906 19:39:57< tad_> Good compiler.  Someone toss it a treat.  Bad code!  Sit. Stay. Someone needs to delete the for loop.
20160906 19:40:05< celmin> XD
20160906 19:40:15< gfgtdf> remove the break i'd say.
20160906 19:40:22< celmin> tad_: The point of the loop seems to be that command-line arguments can request repeated runs.
20160906 19:40:27< JyrkiVesterinen> There are three characters of unreachable code there.
20160906 19:40:28< JyrkiVesterinen> i++
20160906 19:40:31< celmin> Ahh.
20160906 19:40:31< JyrkiVesterinen> The increment.
20160906 19:40:34< gfgtdf> mostlikeley it landed there during some refactor (movng code around9.
20160906 19:41:00< celmin> Suddenly it makes sense.
20160906 19:42:02< tad_> A for with a break is lame.
20160906 19:42:14< tad_> Just unroll it
20160906 19:44:02< tad_> I don't see how "for(;;) break;" ever makes sense.
20160906 19:44:46< gfgtdf> celmin: will you fix it or shall i ?
20160906 19:44:56< celmin> I just removed the break.
20160906 19:44:56-!- irker449 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160906 19:45:03< gfgtdf> celmin: ok
20160906 19:45:09< celmin> tad_: It's for(stuff) {stuff; break;}
20160906 19:45:34< celmin> But pretty sure it's the presence of the break that's wrong, not the existence of the loop.
20160906 19:45:57< gfgtdf> hmm i wonder why i dont get those error since i use msvc aswell.
20160906 19:46:06< tad_> celmin: However you want to word it, the effect is identical to "{}" .. do it once and all you're doing is making it less clear
20160906 19:46:09< celmin> Different version? 
20160906 19:46:23< gfgtdf> hmm maybe
20160906 19:47:26< tad_> The correct replacement code is "if (0 < repeat) then {..."
20160906 19:47:53< tad_> Or since it's unsigned .. if (repeat != 0) then { ...
20160906 19:48:00< JyrkiVesterinen> That is, if you want to preserve the existing semantics.
20160906 19:48:22< JyrkiVesterinen> But most likely it is a bug that the loop can't run more than once.
20160906 19:48:49< tad_> The loop can run 0 or 1 times, but never any more or less
20160906 19:50:45< gfgtdf> does anyone indent to add the misisng overides in thse code? i heared that gcc has a Wsuggest-override flag to find them.
20160906 19:51:05< JyrkiVesterinen> celmin added a bug bunch of them recently.
20160906 19:51:10< JyrkiVesterinen> *big
20160906 19:51:53< celmin> tad_: Pretty sure it can run more?
20160906 19:52:29< tad_> celmin: Nope.  It either runs 0 times or 1 time .. on 1 time it hits the break and goodnight Irene
20160906 19:52:38< celmin> Yeah, I found a bunch when compiling with clang 3.8, but that was -Winconsistent-missing-override, so only in classes that already had at least one marked (and a few obviously related classes).
20160906 19:52:56< celmin> "The object invoked has disconnected from its clients"
20160906 19:53:02< celmin> What the heck does that even mean.
20160906 19:55:52< gfgtdf> no idea
20160906 19:56:25< celmin> It prevents Wesnoth from launching.
20160906 19:56:45< gfgtdf> celmin: debugging or in general ?
20160906 19:57:19< celmin> I don't know how to answer that? It just won't launch.
20160906 19:57:49< gfgtdf> celmin: meaninghow do you start it do you just doubleclick the .exe file ?
20160906 19:57:57< celmin> No, from MSVC
20160906 19:58:07< celmin> …though I got the same thing from double-clicking the exe
20160906 20:02:06< celmin> Google results all seem to be about VBA.
20160906 20:02:13< gfgtdf> celmin: hmm never happend to me. inet entrys are mostly about when debugging  the application but when you just doublelick the exe shoudl usually not start debuggin so that doesnt seem to be it.
20160906 20:02:51-!- irker836 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160906 20:02:51< irker836> wesnoth: Charles Dang wesnoth:master f97dc8ae12be / src/gui/widgets/ (menu_button.cpp toggle_button.cpp toggle_panel.cpp tree_view_node.cpp): Fire a NOTIFY_MODIFIED in all places tselectable_-inherited classes use a custom https://github.com/wesnoth/wesnoth/commit/f97dc8ae12be1b8982ab87b748266f915a84e15d
20160906 20:02:54< celmin> Oh, sorry, it was a different error when I double-clicked.
20160906 20:04:10< celmin> Ah, I found a SO thread about it in VS.
20160906 20:05:03< celmin> It says restarting VS should fix it.
20160906 20:18:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160906 20:21:29-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160906 20:23:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160906 20:25:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160906 20:27:05< irker836> wesnoth: Jyrki Vesterinen wesnoth:master 757367820148 / src/ (31 files in 11 dirs): Fix crash on placing a unit with the scenario editor https://github.com/wesnoth/wesnoth/commit/7573678201483dbfd19a1950c0edfec4487dc19e
20160906 20:27:07< irker836> wesnoth: Jyrki Vesterinen wesnoth:master e82fc498acd7 / src/ (10 files in 4 dirs): Remove the map parameter from the unit::is_visible_to_team() function https://github.com/wesnoth/wesnoth/commit/e82fc498acd7778971bc64ebf1561c2244465152
20160906 20:27:09< irker836> wesnoth: Jyrki Vesterinen wesnoth:master bda24b3f938c / src/ (31 files in 11 dirs): Merge pull request #760 from jyrkive/editor-crashes https://github.com/wesnoth/wesnoth/commit/bda24b3f938c84a75c1fca3372da6ba9f95ced1d
20160906 20:27:49< vultraz> R E F A C T O R I N G
20160906 20:28:41< celmin> Looks like it's working, but for some reason it seems to have gone fullscreen...
20160906 20:29:15< celmin> Maybe it's just a maximized window or something, because fullscreen is unchecked.
20160906 20:31:00< celmin> Well, now it's 800x600. :P
20160906 20:31:26< vultraz> I realize I could have utilized the tfield system to a much greater extent when working on preferences :|
20160906 20:31:46< vultraz> actually I don't utilize it at all :|
20160906 20:32:02< celmin> I was thinking for that to replace the selected callback.
20160906 20:32:09< celmin> But I guess I can do that part.
20160906 20:32:19< vultraz> celmin: two-step process
20160906 20:32:48< celmin> I was imagining .set_callback_state_change() to become a synonym for connecting a NOTIFY_MODIFIED signal.
20160906 20:33:08< vultraz> why not use set_callback_notify_modified directly?
20160906 20:33:43< celmin> Because some places may only have a tselectable_
20160906 20:34:20< celmin> Unless I'm mistaken, set_callback_staet_change is part of tselectable_, so it shouldn't be removed.
20160906 20:34:34< vultraz> it is, but there's no reason not to remove it
20160906 20:35:35< celmin> Yes there is. It's part of the tselectable_ interface.
20160906 20:35:54< vultraz> not if we replace it with NOTIFY_MODIFIED events
20160906 20:37:11< celmin> Yes there is. It's part of the tselectable_ interface.
20160906 20:37:48< vultraz> I don't follow
20160906 20:38:06< celmin> NOTIFY_MODIFIED events are part of the tdispatcher interface.
20160906 20:38:24< celmin> Some things may only have a tselectable_ and still want to install a callback.
20160906 20:38:42< celmin> Keeping it allows them to do so without casting.
20160906 20:38:58< vultraz> blagh
20160906 20:39:08< vultraz> so how do you propose to integrate 
20160906 20:39:41< celmin> The easiest way would probably be to change the implementations of set_callback_state_change to forward the argument to set_callback_notify_modified or the equivalent connect_signal call.
20160906 20:40:44< celmin> Ugh, apparently MSVC clears the error log if you try to run the program. :|
20160906 20:40:53-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160906 20:42:31< celmin> (Of course, you can also remove the callback_state_change_ member.)
20160906 20:44:32< vultraz> I thought you were going to?
20160906 20:44:38< vultraz> I'm busy refactoring prefs :)
20160906 20:44:50< vultraz> to make use of the fields system
20160906 20:44:51< celmin> Sure.
20160906 20:44:53< celmin> I can do it.
20160906 20:45:00< vultraz> for some reason I decided to reinvent the wheel back in March :|
20160906 20:45:06< celmin> Which wheel?
20160906 20:45:45< celmin> (I hope you're not planning to wrap preferences::set in a lambda still...)
20160906 20:46:08< vultraz> the wheel involving basic fields and saving their values :P
20160906 20:46:17< vultraz> and yes, but in a simpler fashion
20160906 20:46:36< celmin> Don't!
20160906 20:46:43< celmin> Ah, so you're refactoring prefs to use tfield?
20160906 20:46:46 * vultraz groans
20160906 20:46:48< vultraz> yes
20160906 20:46:53< celmin> Wrapping it in a lambda is less simple!
20160906 20:46:57< celmin> Not more simple!
20160906 20:47:15< vultraz> [06:19:59]	vultraz	let's take the example using setup_single_toggle. that function took a void(bool) function as its setter. Before, it created a set_ptr to disambiguate the overload, and then passed std::bind(set_ptr, prefname, _1) to setup_single_toggle.
20160906 20:47:17< vultraz> [06:20:17]	vultraz	however, I can now just pass [pref_name](bool v)->void { set(pref_name, v); },
20160906 20:47:18< vultraz> [06:20:24]	vultraz	get rid of bind
20160906 20:47:20< vultraz> [06:20:29]	vultraz	and the set_ptr/set_helper
20160906 20:47:28-!- atarocch_ [~atarocch@93.56.160.28] has quit [Remote host closed the connection]
20160906 20:47:53< celmin> Well, that's not as terrible as what you said before, at least.
20160906 20:48:02< vultraz> yes
20160906 20:48:22< celmin> Okay, it's not how I'd do it, but I guess it's find.
20160906 20:48:24< celmin> ^fine
20160906 20:49:07< celmin> Fields are usually set up in the constructor or post_build, right?
20160906 20:50:06< vultraz> yes
20160906 20:50:29< vultraz> I am changing the initialize_members function to post_build
20160906 20:52:42< celmin> savepng uses setjmp :|
20160906 20:53:30< vultraz> what is setjmp?
20160906 20:54:13< celmin> It's like goto, but between functions.
20160906 20:54:19< celmin> Or exceptions done the C way.
20160906 20:54:23< vultraz> o_O
20160906 20:54:26< vultraz> that's a thing?
20160906 20:54:30< celmin> Yes.
20160906 20:54:32< celmin> It's a function.
20160906 20:54:32< vultraz> you can jump between functions?
20160906 20:54:34< vultraz> wow
20160906 20:54:41< celmin> Yes, with setjmp / exceptions. :P
20160906 20:54:42< vultraz> that seems...dangerous
20160906 20:54:48< celmin> It is, especially in C++.
20160906 20:54:57< celmin> Because it doesn't unwind the stack like exceptions do.
20160906 20:55:29< celmin> (This is why Lua's interaction with exceptions is questionable, because it uses setjmp too… but Lua at least can be configured to use exceptions instead, unlike libpng.)
20160906 20:56:13< celmin> Looks like it's safe in this case.
20160906 20:56:22< celmin> I don't see any C++ objects around it.
20160906 20:58:43-!- JyrkiVesterinen [~JyrkiVest@87-100-211-195.bb.dnainternet.fi] has quit [Quit: Going to bed]
20160906 21:00:32-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20160906 21:10:56-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has joined #wesnoth-dev
20160906 21:10:57< travis-ci> wesnoth/wesnoth#10728 (master - bda24b3 : Jyrki Vesterinen): The build passed.
20160906 21:10:57< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157994886
20160906 21:10:57-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has left #wesnoth-dev []
20160906 21:11:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160906 21:15:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160906 21:30:47< vultraz> blah
20160906 21:30:57< celmin> Blah!
20160906 21:31:03 * celmin should have a push soon for warnings.
20160906 21:31:23< vultraz> so for some reason, now group.set_member_states doesn't accept an int if the group type is an enum :/
20160906 21:31:43< vultraz> plain enum, too
20160906 21:32:12< vultraz> maybe because set_member_states takes a reference?
20160906 21:32:54< vultraz> let's see what happens if it doesn't
20160906 21:33:30< vultraz> changes nothing
20160906 21:33:32< vultraz> hmm
20160906 21:33:58< vultraz> not... sure what to do here
20160906 21:35:00< vultraz> nor do i understand why a class specialization should have an issue with an implicitly convertible type
20160906 21:35:10< vultraz> celmin: or do the types need to be exact?
20160906 21:36:34< vultraz> oh well, I'll just static cast the int to the enum
20160906 21:39:59-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160906 21:40:43< vultraz> hmm
20160906 21:40:52< vultraz> might not be able to use the fields for the advanced prefs
20160906 21:41:01< vultraz> since I think they need....window
20160906 21:42:58< celmin> Total remaining warnings: 12.
20160906 21:43:08< celmin> All of which are in Boost and thus unfixable.
20160906 21:43:24< celmin> vultraz: int is not convertible to enum.
20160906 21:43:31< celmin> enum is convertible to int, but not the reverse.
20160906 21:43:33< vultraz> oh
20160906 21:43:36< celmin> Or rather, not implicitly.
20160906 21:43:38< vultraz> I did not know this
20160906 21:43:57< celmin> You can however explicitly cast an int to an enum, but of course that risks giving you an enum value that isn't actually one of the valid values of the enum.
20160906 21:44:24< celmin> So static cast is indeed the answer, provided you're sure the integer value does correspond to a valid enum value.
20160906 21:46:43< vultraz> I wonder if I should refactor advanced to use a tree view while I'm at it
20160906 21:47:16< vultraz> maybe not right now
20160906 21:49:31< vultraz> or maybe I will
20160906 21:49:33 * vultraz sips coffee
20160906 21:51:21< vultraz> come to think of it, it was originally a tree view
20160906 21:51:40< vultraz> but I think I went for a grid in order to keep the selection box 
20160906 21:51:52-!- Appleman1234 [~Appleman1@KD119104108239.au-net.ne.jp] has quit [Ping timeout: 240 seconds]
20160906 21:53:31< zookeeper> ohh, curious bug (reproduces on 1.12.6): https://forums.wesnoth.org/viewtopic.php?f=21&t=44575
20160906 21:57:05< irker836> wesnoth: Celtic Minstrel wesnoth:master 84e1f4ba4d5e / projectfiles/VC12/ (schema_generator.vcxproj wesnoth.vcxproj wesnothd.vcxproj wesnothlib.vcxproj): MSVC: Ignore truncated type name warnings https://github.com/wesnoth/wesnoth/commit/84e1f4ba4d5e5d4edaa154a45fc74110c2f463f3
20160906 21:57:07< irker836> wesnoth: Celtic Minstrel wesnoth:master 0180a72573a4 / / (14 files in 10 dirs): Fix lots of warnings in MSVC12 https://github.com/wesnoth/wesnoth/commit/0180a72573a482683485821c8d43a82a546a86c6
20160906 22:02:37< vultraz> celmin: so it seems by removing the extra 'setup' function and using set_callback_state_change directly I can now remove the need for the set wrapper altogether
20160906 22:02:47< vultraz> guess SCSC is useful after all
20160906 22:03:10-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 22:09:57< celmin> SCS?
20160906 22:09:59< celmin> SCSC?
20160906 22:10:07< celmin> Oh.
20160906 22:10:17< celmin> Well, I still don't know what you're talking about there, though.
20160906 22:16:22-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 22:17:26-!- travis-ci [~travis-ci@ec2-54-92-226-132.compute-1.amazonaws.com] has joined #wesnoth-dev
20160906 22:17:27< travis-ci> wesnoth/wesnoth#10729 (master - 0180a72 : Celtic Minstrel): The build was broken.
20160906 22:17:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158016975
20160906 22:17:27-!- travis-ci [~travis-ci@ec2-54-92-226-132.compute-1.amazonaws.com] has left #wesnoth-dev []
20160906 22:18:24< vultraz> ermeghard
20160906 22:18:39< vultraz> le buld iz brooken
20160906 22:18:45< celmin> Obviously.
20160906 22:19:13< celmin> Oh, I know why.
20160906 22:22:01< vultraz> booo wesnoth crash
20160906 22:24:19-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160906 22:26:21-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160906 22:26:51< vultraz> celmin: what was the point of the change to lobby_info
20160906 22:26:53< irker836> wesnoth: Celtic Minstrel wesnoth:master e3346fec788d / / (3 files in 2 dirs): Update XCode, scons, CMake https://github.com/wesnoth/wesnoth/commit/e3346fec788d3608b008c1ae0929cee2f7bcd16c
20160906 22:26:54< vultraz> curious
20160906 22:30:36< celmin> Oh, I forgot the header addition. Oh well.
20160906 22:31:14< celmin> vultraz: Apparently, MSVC doesn't silence the warning about "assignment in an if statement" when the assignment is wrapped in an extra pair of parentheses.
20160906 22:31:33< vultraz> I see
20160906 22:39:37-!- Appleman1234 [~Appleman1@KD119104109119.au-net.ne.jp] has joined #wesnoth-dev
20160906 22:43:42 * celmin needs to remember where the new status label binder is… core? auxiliary? dialogs? widgets?
20160906 22:44:16< vultraz> widgets
20160906 22:44:59< celmin> What a weird place for it.
20160906 22:45:42< vultraz> perhaps should be in dialogs
20160906 22:45:53< vultraz> or auxiliary 
20160906 22:48:50< irker836> wesnoth: Celtic Minstrel wesnoth:master 8d6e51367144 / / (3 files in 3 dirs): Fix XCode warnings and add missing header ref https://github.com/wesnoth/wesnoth/commit/8d6e513671442ef1f28047f05d0af7443689df16
20160906 22:51:49< vultraz> +160 -369
20160906 22:51:52< vultraz> *feelsgood*
20160906 22:51:55< celmin> ?
20160906 22:52:00< vultraz> my prefs file diff
20160906 22:52:05< celmin> I see.
20160906 22:52:36< celmin> Oh yeah, tad_ had a problem in settings.cpp?
20160906 22:53:28< celmin> data/gui/_main.cfg does exist, right?
20160906 22:53:29< tad_> I did?
20160906 22:53:34< celmin> I thought you reported that?
20160906 22:53:40< celmin> Something about "No default GUI defined"
20160906 22:53:46< tad_> Ah.
20160906 22:53:55< tad_> Serious mis-match on sync to master.
20160906 22:53:59< celmin> Ah, okay.
20160906 22:54:02< tad_> Rebased and it went away.
20160906 22:54:09< celmin> Good to know.
20160906 22:54:44< tad_> I was testing my HttT PRs and determined that [unit] does exactly what my RECALL_ELSE macro did and forgot it's been a month since last rebase.
20160906 22:55:10< tad_> Just now finished updating the PRs.
20160906 22:56:56< vultraz> for the first time I have lambdas with [=]
20160906 22:56:58< vultraz> :D
20160906 22:57:02< tad_> Got a segfault which probably just needs to be noted and forgotten .. clicked "X" to close window while it was initializing and painting the title screen. Not sure it's worth tracking down ...
20160906 22:57:08< celmin> vultraz: That's suspicious.
20160906 22:57:15< vultraz> why?
20160906 22:57:56< celmin> Because it's making a copy of every parameter and local variable in the function.
20160906 22:58:23< celmin> Now, that might actually be what you want, but...
20160906 22:58:31< tad_> ISTM you can avoid that if you do the lambda properly, tho
20160906 22:58:35< celmin> It might also be copying a lot of things you don't need.
20160906 22:59:01< celmin> ([&] is less suspicious than [=] since it doesn't copy anything)
20160906 22:59:20< celmin> tad_: I don't get what the M is… "I seem to [???]"
20160906 22:59:39< tad_> ?
20160906 22:59:45< vultraz> I probably should have that function a member function anyway
20160906 22:59:49< vultraz> or static
20160906 22:59:51< celmin> tad_: ISTM?
20160906 23:00:05< tad_> Oh. Typoneese for ISTR
20160906 23:00:05< celmin> vultraz: Since I have no idea what it is, I can't say.
20160906 23:00:06< vultraz> i seem to... remember?
20160906 23:00:09< celmin> Ah.
20160906 23:00:42< Aginor> hey guys
20160906 23:00:46< celmin> Hi
20160906 23:01:01< Aginor> thanks for the nominations :)
20160906 23:01:16-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Remote host closed the connection]
20160906 23:01:34< vultraz> Aginor: but did you accept the nomination? :P
20160906 23:02:15< Aginor> vultraz: it's a bit complicated, I need to discuss it with my employer before I can
20160906 23:02:24< vultraz> ah
20160906 23:03:08< celmin> Hey, is there a way to register a string tfield?
20160906 23:03:15< celmin> Like a text box.
20160906 23:03:21< vultraz> yes
20160906 23:03:23< vultraz> register_text
20160906 23:03:26< celmin> Ah, okay.
20160906 23:03:49< celmin> Well, if that's ever needed in the MP Create plugin context, you can do UPDATE_ATTRIBUTE(blah, str)
20160906 23:04:19< celmin> Though I think the string settings currently have separate setters.
20160906 23:06:57< tad_> Just did a quick check on that segfault. It's a race condition in the startup code. If you close the program before it's done initializing the window is gone and SDL2 aint happy about it.
20160906 23:07:32< celmin> Is that the t_string crash that I occasionally get?
20160906 23:07:39< celmin> Or a different rac condition?
20160906 23:07:41< celmin> ^race
20160906 23:07:49 * tad_ shrugs.
20160906 23:08:17< Aginor> tad_: why do you say SDL2 is unhappy? - what led you to that conclusion?
20160906 23:08:35< tad_> For me it's "I want to see the console message to check the version, commit number and if it's "Clean" and it aint happy I closed so quickly.
20160906 23:09:12< celmin> You could launch from console with --version
20160906 23:10:03< tad_> celmin: Where's the fun in that? :D
20160906 23:10:08< celmin> Who knows!
20160906 23:10:47< tad_> Aginor: A lot of lines which look like what happens if vultraz commits a change to a screen and I forget to rebase.
20160906 23:12:11< tad_> Might be SDL2 might be how SDL2 is being used might be someone skipped some error checks. Not sure it's worth tracking down and probably a lot of little errors and which I hit depends on which millisecond I hit "X" on
20160906 23:14:48< tad_> In this case it was (gdb) backtrace #0  std::local_Rb_tree_decrement (__x=0x7fffdc0a1128) at /build/gcc/src/gcc/libstdc++-v3/src/c++98/tree.cc:110
20160906 23:17:06< tad_> (gdb) backtrace #0  0x00007ffff291004f in raise () from /usr/lib/libc.so.6Yep .. timing dependent .. 
20160906 23:19:54< tad_> But, really, how often does someone close before the program is up and care whether it exited cleanly or crashed?
20160906 23:20:08< celmin> Probably not very often.
20160906 23:20:30< tad_> "I wanted it gone. It's gone. I'm happy."
20160906 23:21:26< tad_> Only side-effect is a core file which will go away in a couple days when cron cleans my /temp ...
20160906 23:23:16< Aginor> I disagree there
20160906 23:23:45< Aginor> because most OSes will give you a little prompt saying that "blah stopped working, do you want to submit an error report"
20160906 23:24:07< tad_> Well, have fun. Where it crashes depends on precisely when I click "X" to close the window so it's probably a whole lot of little errors.
20160906 23:24:46< celmin> The existence of race conditions in the startup code has been known for awhile now.
20160906 23:25:03< celmin> But no-one seems to know how to deal with them.
20160906 23:25:48< tad_> It's the sort of problem which, back in the day, I'd assign to a new hire junior programmer to get him familiar with the mess we have to deal with.
20160906 23:36:28-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds]
20160906 23:43:04< mattsc> celmin: I’m read to commit the AI “support bug” fix.  Let me know if 
20160906 23:43:10< mattsc> I should wait for something.
20160906 23:43:12< celmin> Nah
20160906 23:43:24< mattsc> okay then
20160906 23:45:57< irker836> wesnoth: mattsc wesnoth:master e7bd4bc4efa3 / RELEASE_NOTES changelog src/ai/default/attack.cpp: Default AI: fix bug causing units with max_moves=0 not to attack https://github.com/wesnoth/wesnoth/commit/e7bd4bc4efa3c38dee2bab0c6b966b4caf5bc115
20160906 23:46:36< vultraz> noooo a commit :(
20160906 23:46:55< mattsc> vultraz: I just asked …
20160906 23:47:02< mattsc> although not you directly
20160906 23:47:08< vultraz> i wasn't paying attention
20160906 23:47:10< vultraz> oh well
20160906 23:47:32< mattsc> sorry ...
20160906 23:47:36< mattsc> vultraz: one the positive side, this fixes a bug you submitted: https://gna.org/bugs/?23720
20160906 23:47:39< vultraz> merge commit it is
20160906 23:47:53< vultraz> ah, sweet :D
20160906 23:48:01< vultraz> though I don't remember why i needed that anymore
20160906 23:48:09< gfgtdf> how is that a merge commit ?
20160906 23:48:12< celmin> Merge commits are annoying. :/
20160906 23:48:36< vultraz> I was considering keeping a merge commit
20160906 23:48:40< celmin> What?
20160906 23:49:22< vultraz> stash/rebase/stash pop causes a rebuild of the stashed files for me
20160906 23:49:25< vultraz> since i dont have ccache
20160906 23:49:32< vultraz> and i had modified dialog.hpp 
20160906 23:49:42< celmin> If it's only one commit, you could reset --soft HEAD^
20160906 23:49:45< celmin> Then recommit.
20160906 23:49:59< celmin> Oh, and pull --ff-only between those.
20160906 23:52:47< irker836> wesnoth: Charles Dang wesnoth:master ba81174ade32 / projectfiles/CodeBlocks/wesnoth.cbp: Updated CB projfile https://github.com/wesnoth/wesnoth/commit/ba81174ade324bb00a6e74abee692153d3209c50
20160906 23:52:48< vultraz> let's get these out
20160906 23:52:51< irker836> wesnoth: Charles Dang wesnoth:master df5177678065 / src/gui/widgets/status_label_helper.hpp: Added two small features to the status label helper https://github.com/wesnoth/wesnoth/commit/df5177678065ba588f84802e89550b6e6d082204
20160906 23:52:54< irker836> wesnoth: Charles Dang wesnoth:master 84759a2713f6 / src/gui/ (auxiliary/field.hpp dialogs/dialog.cpp dialogs/dialog.hpp): Added flag to register_bool to enable an initial firing of the passed callback e https://github.com/wesnoth/wesnoth/commit/84759a2713f687b3cf0ef7c36fae394e4c997898
20160906 23:53:20< celmin> Debugging in MSVC is so much more pleasant.
20160906 23:53:29< celmin> For example, I can actually view the contents of a config.
20160906 23:54:02< vultraz> MSVC? pleasant?
20160906 23:54:02-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160906 23:54:44< celmin> Yes, it's actually a pretty good IDE.
20160906 23:54:55< celmin> XCode is fairly good too, mind you.
20160906 23:55:18< vultraz> I have not had pleasant experiences with MSVC
20160906 23:55:27< vultraz> it takes 4x longer to build wesnoth, for one
20160906 23:55:40< celmin> I dunno about build times.
20160906 23:55:45< celmin> But the debugger is pretty good.
20160906 23:56:22< celmin> In XCode it's impossible for me to see the contents of a config, partly due to all the obfuscation in the standard library.
20160906 23:56:51< celmin> Also partly because sometimes variable viewing simply fails for no apparent reason.
20160906 23:57:17-!- fabi [~fabi@176.0.92.222] has joined #wesnoth-dev
20160906 23:58:16< celmin> MSVC also helpfully shows relevant partial expressions in the variable viewer as you step through. XCode only shows the actual variables.
20160906 23:59:52-!- fabi_ [~fabi@176.4.56.57] has quit [Ping timeout: 240 seconds]
--- Log closed Wed Sep 07 00:00:56 2016