--- Log opened Fri Jul 29 00:00:48 2016
20160729 00:01:02< zookeeper> i fail to see why the quenoth should be in core more than any other campaign-only units.
20160729 00:01:30< zookeeper> because they're used by (many?) UMC?
20160729 00:01:39< celmin> There are quite a few campaign-only units already in core. (Maybe for historical reasons, I guess.)
20160729 00:01:57< celmin> If they're used by a lot of UMC, that could be a reason.
20160729 00:06:41< celmin> Of course, the problem with importing something like aragwaithi is, which version do you take>
20160729 00:06:47< celmin> ^?
20160729 00:07:14< celmin> Maybe some version of it is MP-balanced, though I dunno if that's with respect to the core factions...
20160729 00:07:37< zookeeper> surely no one would seriously try to mainline aragwaithi
20160729 00:10:07< celmin> I dunno.
20160729 00:10:12< shadowm> Surely no-one would drop a vacuous comment like that without elaborating on the reasons.
20160729 00:10:16< celmin> Do you have a reason for that?
20160729 00:10:28< celmin> Thanks shadowm :p
20160729 00:14:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160729 00:17:35< zookeeper> i don't have specific reasons for not mainlining aragwaithi, or a slime faction, werewolves or celestials
20160729 00:17:59< zookeeper> if there are any reasons which make any of those even remotely fit for consideration, then i've missed them
20160729 00:18:57< celmin> I seem to recall aragwaithi being mentioned for consideration awhile back, but can't remember if good reasons were given.
20160729 00:20:47< zookeeper> you seem to be saying that you'd be interested in doing something that you know of no good reason to do?
20160729 00:21:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160729 00:21:44< celmin> I'd be interested in mainlining more factions and brought of aragwaithi as a possible example since I recalled it coming up before.
20160729 00:21:50< celmin> ^brought up
20160729 00:23:26< zookeeper> i see
20160729 00:25:11< zookeeper> i think it's pretty apparent though that we have no capability to actually mainline more factions in any meaningful sense
20160729 00:25:22< zookeeper> that's referring to the khalifate, in case it's not obvious
20160729 00:26:47< iceiceice> that might be partly because its been made so difficult that a large number of people have lost interest or faith that its even possible
20160729 00:26:54< celmin> What exactly makes this apparent?
20160729 00:29:05< zookeeper> iceiceice, i prefer "it's become" rather than "it's been made" :p i mean it simply is harder to add completely new stuff now than 10 years ago.
20160729 00:30:29< zookeeper> celmin, the way the khalifate is a mess and no developer apparently is interested in it and/or wants to touch it?
20160729 00:31:02< celmin> What do you mean by saying it's a mess?
20160729 00:31:21< iceiceice> zookeeper, idk if the bar is set too high that no one can reach it
20160729 00:31:29< iceiceice> then maybe that means there should be a new mechanism
20160729 00:31:46< iceiceice> like, maybe we should plan for a second default era or something
20160729 00:31:58< celmin> Is it difficult because of balancing issues, or is it something else?
20160729 00:32:05< celmin> iceiceice: An "After the Fall" era might be cool.
20160729 00:32:13< celmin> (An official one, I mean.)
20160729 00:32:24< iceiceice> partly its the balancing, partly its that getting a campaign mainlined is very difficult
20160729 00:32:34< iceiceice> there are several drake campaigns but none got mainlined
20160729 00:32:34< celmin> I was thinking more about MP factions.
20160729 00:32:42< iceiceice> and drakes were added like forever ago
20160729 00:35:57< iceiceice> i agree with zookeeper that the khalifate thing is kind of a mess
20160729 00:36:10< iceiceice> but i also have no idea what to do about that
20160729 00:36:16< celmin> How exactly is it a mess?
20160729 00:36:29< iceiceice> well
20160729 00:36:41< iceiceice> there are no campaigns for it, no one working on them,
20160729 00:37:00< celmin> There's at least one campaign for it.
20160729 00:37:02< iceiceice> it turns out that many of the users and a significant number of the devs dont like all the names of the units and want more "normal" names
20160729 00:37:08< iceiceice> idk
20160729 00:37:10< celmin> I was going to use a hakim in my next campaign too.
20160729 00:37:19< celmin> I can see the point on the names.
20160729 00:37:23< iceiceice> there was a really annoying thread where people said the religious theme is offensive
20160729 00:37:31< iceiceice> i basically argued against that strongly
20160729 00:37:33< zookeeper> celmin, it's a mess in the sense that it was created as an empty gameplay-only shell without any sensible backstory or without any concern for how it'd be integrated story-wise, no developers are interested in it, the units have obfuscated arabic names, and... well, that's my usual gripes
20160729 00:37:34< celmin> I think those people are best ignored.
20160729 00:37:48< celmin> I'm interested in it.
20160729 00:37:52< iceiceice> thats good
20160729 00:37:58< iceiceice> so i guess from the MP perspective,
20160729 00:38:10< iceiceice> my opinion is that the khalifate is grossly imbalanced in default era,
20160729 00:38:14< iceiceice> i'm not that good,
20160729 00:38:14< zookeeper> well, great if someone is
20160729 00:38:15< celmin> I think changing the names would be good actually. Perhaps adding redundancy - eg "Arif Swordsman", or "Junwhatever Bowman".
20160729 00:38:24< iceiceice> but from what i understand most of the highly ranked ladder players agree
20160729 00:38:34< celmin> Not sure if that's sensible though.
20160729 00:38:38< iceiceice> except that
20160729 00:38:48< zookeeper> so in short, it'
20160729 00:38:54< iceiceice> some of the highly ranked ladder playesr basically say that the whole default era is grossly imbalanced
20160729 00:38:58< celmin> Are there suggestions for fixing imbalances?
20160729 00:39:01< iceiceice> and that khalifate doesn't make it significantly worse
20160729 00:39:07< celmin> …heh.
20160729 00:39:20< iceiceice> i think there are serious imbalances related to knalga
20160729 00:39:31< iceiceice> they tend to be either very over powered or underpowered
20160729 00:39:37< iceiceice> in a typical matchup
20160729 00:39:46< iceiceice> like they are very very strong vs undead
20160729 00:39:52< iceiceice> and very weak vs loyals or drakes
20160729 00:40:07< celmin> And the goal is to avoid rock-paper-scissor factions, I suppose?
20160729 00:40:12< iceiceice> yeah
20160729 00:40:19< iceiceice> idk
20160729 00:40:25< iceiceice> khalifate is a very strange faction though
20160729 00:40:29< celmin> I think that makes sense as a goal though.
20160729 00:40:35< iceiceice> like
20160729 00:40:48< iceiceice> i think i just dislike the way the units are designed, i dont know what else i can say
20160729 00:40:55< iceiceice> the rami is like extremely fast
20160729 00:41:00< iceiceice> and much tankier than an elf archer
20160729 00:41:05< iceiceice> and doesn't do significantly less damage
20160729 00:41:20< iceiceice> and it gets 60% in hills
20160729 00:41:24< iceiceice> which doesn't really make any ense
20160729 00:41:25< iceiceice> *sense
20160729 00:41:30< iceiceice> given how the other cavalry work
20160729 00:41:50< iceiceice> i think the rami is very overpowered against drakes
20160729 00:41:59< iceiceice> again i'm not an expert
20160729 00:42:06< iceiceice> thats just my opinion having played some games though
20160729 00:42:10< celmin> Speaking of cavalry, the merging line of qanas is weird.
20160729 00:43:28< iceiceice> i really dont like the fire archer either, i think the melee needs to change
20160729 00:43:38< iceiceice> its really really nasty for undeads
20160729 00:43:45< iceiceice> if when you hit some unit in melee that is supposed to be squishy
20160729 00:43:50< iceiceice> it actually does like impact or fire
20160729 00:44:09< iceiceice> there was a very highly rated player who suggested that footpad melee be changed to blade or pierce
20160729 00:44:15< iceiceice> basically to help undead vs knalgan
20160729 00:44:17< celmin> Well, one of the wolf riders also has fire melee.
20160729 00:44:22< iceiceice> yeah but thats a level 2
20160729 00:44:28< celmin> Fair enough I guess.
20160729 00:44:34< iceiceice> the footpad is in theory a ranged unit
20160729 00:44:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 00:44:54< celmin> I think blade could make sense for it, not sure if it's a good idea though.
20160729 00:45:05< iceiceice> yeah...
20160729 00:45:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160729 00:45:14< iceiceice> it sort of harms the thematics, and we already have the club sprite
20160729 00:45:17< celmin> Balance is important, but so is flavour.
20160729 00:45:19< celmin> Yeah.
20160729 00:45:26< iceiceice> but i think it would help default era balance
20160729 00:45:32< iceiceice> because it basically doesnt matter in any other matchup
20160729 00:47:04< iceiceice> on most maps, if i play as knalgan vs undead
20160729 00:47:13< iceiceice> basically i just spam footpads and make an ulf for each front
20160729 00:47:30< iceiceice> i learned that from cackfiend's replays i guess
20160729 00:47:45< iceiceice> usually there's nothing that undead can do against that
20160729 00:48:07< celmin> Though, ghosts aren't that weak to impact, are they?
20160729 00:48:15< iceiceice> they also don't really do any damage
20160729 00:48:20< iceiceice> you just surround them and range them
20160729 00:48:26< celmin> Yeah okay.
20160729 00:48:50< celmin> Ghouls?
20160729 00:49:40< zookeeper> iceiceice, WRT what you said about rami: that's one of my high-level problems with the idea of just adding more stuff. when you keep adding more stuff, you need the new stuff to be different from the old, and there's only so much you can do without stepping on the old stuff's toes.
20160729 00:49:41< zookeeper> you end up with cavalry that doesn't feel like cavalry, or archers that are better than elvish archers, or defenses/resistances that don't make sense next to the old stuff. new stuff needs to be justified by new gimmicks, but you can't keep adding new gimmicks without affecting the coherency of the whole... if that makes sense.
20160729 00:50:01< celmin> Kinda
20160729 00:50:22< celmin> Though I'd say it has to be different broadly, not narrowly...
20160729 00:51:08< zookeeper> (that's not to say that original core units are somehow magically all coherent, they're not)
20160729 00:51:22< iceiceice> celmin, so thats interesting,
20160729 00:51:34< iceiceice> the ghouls seem like they might be a good idea, but they are very weak to impact
20160729 00:51:42< iceiceice> and the footpads are all impact
20160729 00:51:43< celmin> Oh.
20160729 00:51:52< iceiceice> actualy horus has an experimental era
20160729 00:52:03< iceiceice> where he basically changed the ghoul resists so that they are weak to blade rather than impact
20160729 00:52:08< celmin> All that leaves is adepts, corpes, and bats… none of which seem good...
20160729 00:52:12< celmin> ^corpses
20160729 00:52:18< iceiceice> i think what you are supposed to do is like
20160729 00:52:21< iceiceice> kill the footpads with adepts
20160729 00:52:27< iceiceice> but its pretty hard
20160729 00:52:29< iceiceice> idk
20160729 00:52:33< iceiceice> the footpads are faster than everything you have
20160729 00:52:58< iceiceice> if you get at all unlucky with the adepts then you just get ulfed and clubbed
20160729 00:53:10< iceiceice> the ghouls are basically like
20160729 00:53:13< iceiceice> ghouls are a defensive unit
20160729 00:53:18< iceiceice> they aren't really an attacking unit
20160729 00:53:30-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160729 00:53:45< iceiceice> you can't really afford to make too many ghouls
20160729 00:53:53< celmin> Ghouls weak to blade could make sense, I suppose.
20160729 00:54:36< celmin> I dunno, I'm not a person to be suggesting balance changes really
20160729 00:55:19< iceiceice> zookeeper, yeah i agre with that
20160729 00:55:25< iceiceice> about coherency of the whole
20160729 00:55:47< iceiceice> but it would be nice if there were a way for people to still contribute new stuff
20160729 00:55:53< zookeeper> high-level balance tweaking also has a tendency to result in somewhat ill-fitting things, like feral on bats, orcish assassins having marksman...
20160729 00:56:39< iceiceice> i mean
20160729 00:57:07< celmin> What's wrong with orcish assassins having marksman?
20160729 00:57:39< celmin> Human assassins don't have it though...
20160729 00:57:55< zookeeper> celmin, because they're orcs and shouldn't be inhumanly accurate?
20160729 00:58:08< celmin> Marksman is unhuman accuracy?
20160729 00:58:17< iceiceice> yeah but the orcs need to be able to somehow hit the dwarves on the mountains
20160729 00:58:20< celmin> ^inhuman
20160729 00:59:14< zookeeper> celmin, yeah, more or less, considering how only an elvish marksman can be that accurate with a bow
20160729 00:59:26< zookeeper> iceiceice, exactly
20160729 00:59:36< celmin> I thought someone else had marksman...
20160729 00:59:53< zookeeper> well, arif has melee marksman :p
20160729 01:00:02< celmin> I wasn't thinking of that.
20160729 01:00:02< iceiceice> and the orcish assassin has it :p
20160729 01:00:15< iceiceice> what is the flavor text for marksman actually?
20160729 01:00:22< celmin> Drake glider.
20160729 01:00:30< zookeeper> oh right, glider too
20160729 01:00:34< celmin> Huntsman (L3(
20160729 01:00:36< celmin> ^)
20160729 01:00:43< celmin> Dragon, heh
20160729 01:00:46< zookeeper> urgh, huntsman too. my memory's failing
20160729 01:00:59< zookeeper> so, yeah, marksman's suffered from serious inflation
20160729 01:01:21< iceiceice> hehe
20160729 01:01:22< celmin> Might be significant that the only human to have it is the huntsman though, I dunno.
20160729 01:01:46< zookeeper> well, is a human huntsman better with a bow than an elvish ranger? seems a bit dubious
20160729 01:01:56< celmin> Well, the arif I guess.
20160729 01:02:00< iceiceice> so another often requested balance change is that poachers need a buff somehow
20160729 01:02:09< iceiceice> like that they could be dextrous or something
20160729 01:02:19< iceiceice> but that goes agains the thematics quite directly :p
20160729 01:02:31< celmin> Huntsman 9-4, elf ranger 7-4, elf avenger 10-4
20160729 01:02:34< iceiceice> idk if thats actually why it never happened
20160729 01:02:50< celmin> Dunno if damage is relevant to the question, but it's the only way I can think of to compare them.
20160729 01:02:55< zookeeper> to be fair, my problem with orcish assassins having marksman is more about it having two specials, than one of them being marksman
20160729 01:05:35< zookeeper> because that was unprecedented and i think it retroactively makes other things nonsensical. why isn't entangle magical too, etc.
20160729 01:06:02< celmin> Huh, they do seem to be the only one with two specials on the same weapon.
20160729 01:06:44< iceiceice> idk there are always exceptions to rules
20160729 01:07:02< iceiceice> i think most people can accept that entangle is not magical for balance reasons
20160729 01:07:24-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: Warning! 7-day exploit detected! For your health and safety, we have disabled your Internet. Please call your local Zen temple for instructions on updating your service.]
20160729 01:08:38< zookeeper> iceiceice, sure, but again, thematically you'd expect the exceptions to be the truly exceptional units. orcish assassins don't exactly fit that role
20160729 01:08:55-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160729 01:09:00< celmin> What does fit that role?
20160729 01:09:02< iceiceice> why not?
20160729 01:10:22< zookeeper> iceiceice, well, because they're orcs who are brutes, they look a bit goofy and thus unskilled, and they're lvl1 so they just can't be that good yet anyway
20160729 01:11:28< zookeeper> an orc gets marksman at lvl1 with throwing knives, an elf gets marksman at lvl2 with a bow. i mean that's obviously not how you'd design things from scratch.
20160729 01:11:39< celmin> I guess it is weird that they get it at level 1.
20160729 01:11:46< iceiceice> ok, its one thing to say that "orcs are thematically a horde and each individual is unexceptional"
20160729 01:12:00< iceiceice> but ideally we want orcs to be balanced against the other races
20160729 01:12:05< iceiceice> when they are played in multiplayer
20160729 01:12:28< iceiceice> so idk if the theme should go so far as justifying a handicap
20160729 01:12:36< celmin> Not quite (factions are not races), but close enough
20160729 01:12:57-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160729 01:13:13< celmin> Hi ancestral, did you get your build to work yet?
20160729 01:13:19< iceiceice> i mean the orcish assassin is otherwise pitiful
20160729 01:13:22< iceiceice> hes very frail
20160729 01:13:26< iceiceice> and does very little damage
20160729 01:13:34< iceiceice> without the poison and the marksman he would need lots of other buffs
20160729 01:13:44< ancestral> celmin: Yes, it never not built after modifying the Boost library
20160729 01:13:44< iceiceice> so i dont think the two specials makes him seem exceptional
20160729 01:13:58< ancestral> The issue is modifying the Boost library may have unintended consequences
20160729 01:14:06< celmin> ancestral: Which modification did you do?
20160729 01:14:23< ancestral> The BOOST_STATIC_ASSERT in arg.hpp
20160729 01:14:30< celmin> So removing the constexpr didn't help?
20160729 01:14:39< celmin> I noticed gfgtdf suggesting that.
20160729 01:14:51< ancestral> per gfgtdf, removing BOOST_CONSTEXPR in the template DID help
20160729 01:14:54< zookeeper> iceiceice, of course, but my point was exactly that sometimes those kind of balance tweaks do create thematic problems. even if this particular problem isn't that huge. so there's this risk of things slowly deviating from a coherent whole into a bit of a jumbled mess (an exaggeration), one small individually necessary tweak at a time.
20160729 01:14:56< ancestral> That did remove the error
20160729 01:15:32< zookeeper> iceiceice, and i'm not saying that there's any magic bullet solution to that
20160729 01:15:40< zookeeper> since balance tweaks still need to happen
20160729 01:15:43< iceiceice> yeah i see
20160729 01:15:55< ancestral> If there’s a way to analyze game data, with the Steam release, we could potentially have access to many, many more games
20160729 01:16:04< celmin> ancestral: Removing that shouldn't have any bad consequences; at most it might reduce optimization or something.
20160729 01:16:27< celmin> constexpr is meant to tell the compiler "you can evaluate this at compile-time if you want".
20160729 01:16:57< ancestral> celmin: Right, so I’m not worried, but long term, we need to figure out a way to fix this without modifying a third-party library 
20160729 01:17:01< celmin> So if it works without constexpr but with the static_assert, that seems a valid workaround for now.
20160729 01:17:15< celmin> Yeah, but we don't need to do that before releasing 1.13.5.
20160729 01:17:27< celmin> Did we have any other blockers pending besides your inability to build?
20160729 01:17:34< celmin> Because if not, maybe we can get the release going finally.
20160729 01:17:39< ancestral> I figured out commenting out the whole thing built successfully last week
20160729 01:18:08< ancestral> We could get the release going as far back as Sunday
20160729 01:18:35< celmin> Yeah, probably, as your issue didn't really need to be resolved prior to tagging.
20160729 01:18:37< ancestral> Like I said about a dozen times, I didn’t know what kind of consequences we would run into by messing with the STATIC_BOOST_ASSERT
20160729 01:18:49< celmin> RIght, I don't know if that would be safe either.
20160729 01:19:01< ancestral> But hey, this is dev
20160729 01:19:03< celmin> It basically implies that the function might be called in unexpected circumstances.
20160729 01:19:08< ancestral> This isn’t stable
20160729 01:19:10< celmin> (Well, the constructor in this case.)
20160729 01:19:34< zookeeper> iceiceice, i just think that it's good to be aware of those kinds of things when making balance changes, to make sure that if a thematically problematic change is made, it really is because it was the only feasible option.
20160729 01:19:35< celmin> Didn't you just say it works with the static_assert if you take out the constexpr?
20160729 01:19:42< celmin> Or did one of us misunderstand?
20160729 01:19:59< zookeeper> iceiceice, which perhaps it was WRT the assassin, i wouldn't know.
20160729 01:20:06< iceiceice> zookeeper, yeah i see that
20160729 01:20:20< iceiceice> i guess that over time the balance changes will accumulate
20160729 01:20:35< iceiceice> idk how you can make thematics correction changes
20160729 01:20:43< iceiceice> i guess you need to force those in too sometimes
20160729 01:20:45< iceiceice> hehe
20160729 01:20:51< zookeeper> can't really, i suppose
20160729 01:21:10< celmin> Might help if someone kept a list of thematic problems.
20160729 01:21:27< zookeeper> i mean, mages should have bad physical resistances just like elusivefoots. but i'm pretty sure there's no way to actually do that without MP balance being seriously affected.
20160729 01:21:32< celmin> But the trouble is that theme and balance are in competition.
20160729 01:21:59< iceiceice> thats a good point
20160729 01:22:15< zookeeper> yes, that's the problem
20160729 01:22:16< celmin> Which one? :P
20160729 01:22:17< iceiceice> you might be able to put that in, idk
20160729 01:22:38< iceiceice> mages are not like *that* crucial in most matchups
20160729 01:22:53< iceiceice> you already cant usually get more than a few
20160729 01:23:15< iceiceice> they are already pretty frail anyways
20160729 01:23:22< iceiceice> i mean the 24 hp mage even without elusive foot
20160729 01:23:29< iceiceice> its very difficult to keep that guy alive
20160729 01:23:53< iceiceice> idk what would be harmed, i guess it would give undead an advantage
20160729 01:24:16< iceiceice> undead probably need help vs the rebels
20160729 01:24:21< zookeeper> and like, doing balance changes early on is easier because you have a bit more leeway, but when the balance is better, it's much more delicate and if you really need one unit or faction to be better against X on terrain Y at ToD Z, then... you have much fewer options and might have to add some kind of ill-fitting exception to cover that need.
20160729 01:24:24< iceiceice> they have a really hard time to kill woses
20160729 01:24:38< celmin> I think it would be good to have a list of thematic concerns so that balance changes can attempt to account for them whenever possible.
20160729 01:24:49< iceiceice> hehe
20160729 01:24:56< iceiceice> i think it would be hard to enumerate thematic concerns
20160729 01:25:06< celmin> Actually, it might be good to try to enumerate balance concerns too.
20160729 01:25:26< iceiceice> i mean ideally everyone who was proposing changes would just be an expert in all fronts
20160729 01:25:27< iceiceice> :)
20160729 01:25:57< iceiceice> i think jury is out on loyals vs undead
20160729 01:26:11< iceiceice> i always thought loyals had an advantage here, but i think at higher levels they dont
20160729 01:26:13< celmin> It might be hard to enumerate thematic concerns, but I think making the attempt would be useful even if it's not a complete list.
20160729 01:26:17< zookeeper> i think most of my thematic concerns have been enumerated in this discussion already, i don't think there's _that_ many of them (amont non-khalifate core units, anyway)
20160729 01:26:36< zookeeper> celmin, but yeah maybe it could be useful
20160729 01:26:57< Aginor> would it be worth to fork out some money for http://www.macincloud.com/ to ensure that we can solve ancestral's problems properly?
20160729 01:27:26 * zookeeper will now go to bed at 4:30AM
20160729 01:27:31< celmin> Oh my!
20160729 01:27:34< celmin> :P
20160729 01:28:00< Aginor> zookeeper: sleep well :)
20160729 01:28:08< celmin> That too.
20160729 01:28:36< iceiceice> i was bummed that we had to revert the mushroom grove change in 1.12
20160729 01:28:42< celmin> Which change?
20160729 01:28:44< iceiceice> i guess probably its not coming back either in 1.14
20160729 01:29:00< iceiceice> celmin, a long standing thing has been that
20160729 01:29:15< iceiceice> mushroom groves are not a dual terrain type like forests
20160729 01:29:30< iceiceice> if theres mushrooms on a tile, it wipes out the base terrain for purposes of game play
20160729 01:29:44< celmin> Oh, weird.
20160729 01:29:52< iceiceice> there's no particular reason for that, its just some legacy thing i guess
20160729 01:29:58< iceiceice> we could have mushrooms be a dual terrain type
20160729 01:30:01< celmin> Mushroom is a separate terrain type as well, right?
20160729 01:30:10< iceiceice> and then it would like, allow you to make intersting mixtures
20160729 01:30:21< iceiceice> like sand mushroom or hill mushroom would be fundamentally different
20160729 01:30:29< iceiceice> than the terrains that we previously had
20160729 01:30:32< celmin> Sand mushroom sounds really weird.
20160729 01:30:58< iceiceice> yeah i guess so
20160729 01:31:10< iceiceice> i'm trying to think now of why you would do that :p
20160729 01:31:16< celmin> Thinking about this logically, if there's some combination that's identical to the original mushrooms, then it might be doable somehow? But having an identical combination may be impossible, I dunno.
20160729 01:31:30< iceiceice> i mean you can make flat + mushroom
20160729 01:31:36< iceiceice> and i think thats the same as mushroom probably
20160729 01:31:47< iceiceice> we worked this out at the time
20160729 01:31:49< iceiceice> i think it was like
20160729 01:31:54< iceiceice> so there are some units like cavalry
20160729 01:32:03< iceiceice> that get "- " defense modifiers on forests
20160729 01:32:14< celmin> ?
20160729 01:32:15< iceiceice> which means that they get only 30% on forests, and only 30% even on forested hills
20160729 01:32:15-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20160729 01:32:26< iceiceice> the defense caps or whatever
20160729 01:32:38< celmin> Okay, not super-important, continue?
20160729 01:32:46< iceiceice> you would have to add defense caps on mushrooms
20160729 01:32:48< iceiceice> for like
20160729 01:32:52< iceiceice> gryphons, and all cavalry i think
20160729 01:33:05< iceiceice> and then mushroom flat would be the same as mushroom currently is
20160729 01:33:16< celmin> I see...
20160729 01:33:22< iceiceice> but i think
20160729 01:33:28< iceiceice> some people dont even like the whole defense caps thing
20160729 01:33:43< iceiceice> but its hard to see how to remove it for forests to begin with
20160729 01:34:03< iceiceice> anyways there were some commits to make mushroom a dual thing
20160729 01:34:16< iceiceice> and there was an outcry on the forums and it got reverted
20160729 01:34:29< iceiceice> shortly before 1.12 release
20160729 01:34:47< celmin> Sounds like something good to me, but if there was an outcry, maybe not… :/
20160729 01:35:03< iceiceice> idk i think the arguments didn't really make sense
20160729 01:35:10< celmin> Did it update maps using mushrooms as well? Did the outcry point out how it changed things?
20160729 01:35:10< iceiceice> mainly it was just like, a backwards compat thing
20160729 01:35:32< iceiceice> like tekelili really didn't like it because he didn't want to have to adapt to it
20160729 01:35:44< iceiceice> and he said that he liked being able to decorate the map using things under mushrooms
20160729 01:35:48< iceiceice> knowing that it has no balance impact
20160729 01:36:01< iceiceice> i thought that was a pretty weak argument :p
20160729 01:36:15< celmin> Given that MP maps look pretty patchwork...
20160729 01:36:56< iceiceice> this shouldn't really be an issue, it should be easier to just ship whatever custom terrains you want
20160729 01:37:20< celmin> Well, custom terrains are hard in general.
20160729 01:37:23< iceiceice> but it turns out that most mp addon makers avoid that at all costs, because if your addon requires download then no one will play it
20160729 01:37:36< iceiceice> or at least that was perception at one point
20160729 01:37:43< celmin> So if requiring download is no longer an issue, that could change.
20160729 01:37:50< iceiceice> maybe
20160729 01:37:51< celmin> (For example, if auto-download is implemented.)
20160729 01:38:17< celmin> (Alternatively, send the entire addon WML across the network instead of just the scenario, or something.)
20160729 01:38:36< celmin> (I guess that's similar to auto-download.)
20160729 01:38:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 01:38:48< iceiceice> i never thought of that
20160729 01:39:00< celmin> Huh?
20160729 01:39:07< celmin> Sending the entire addon WML?
20160729 01:39:11< iceiceice> well like
20160729 01:39:14< iceiceice> the add-on may contain png also
20160729 01:39:20< celmin> (It could be a bit of a problem with MP campaigns I guess.)
20160729 01:39:20< iceiceice> i can't remember how the add-on server handles that
20160729 01:39:29< celmin> Oh right, there's also non-WML assets, true.
20160729 01:39:45< celmin> So auto-download would probably be easier.
20160729 01:39:47< iceiceice> iirc the addon server uses this janky one off data transfer format
20160729 01:39:55< iceiceice> where like binary data is escaped into a string basically
20160729 01:39:57< iceiceice> and that is sent as wml
20160729 01:40:19< celmin> Makes sense (apart from the obvious question of why on earth would you do it that way).
20160729 01:40:32< iceiceice> idk you would have to ask dave :)
20160729 01:40:34< iceiceice> iirc
20160729 01:41:05< celmin> Once the campaign server is ported to asio I'll probably add it to XCode so maybe I can try looking at it a bit… not sure if I'll do anything though...
20160729 01:41:13< iceiceice> yeah i mean
20160729 01:41:24< iceiceice> theres no reason the addon server couldn't just be like a normal http server
20160729 01:41:33< iceiceice> except that you could break everything :)
20160729 01:41:41< celmin> What do you mean, break everything?
20160729 01:41:44< iceiceice> stability of add-on server is pretty important i think
20160729 01:41:49< iceiceice> idk
20160729 01:41:55< iceiceice> if addon server stopped working that would be pretty bad
20160729 01:42:07< iceiceice> and it works fine right now
20160729 01:42:08< celmin> I don't think add-ons server needs to be compatible between major versions, though?
20160729 01:42:17< iceiceice> thats true
20160729 01:42:17< celmin> So it could be rewritten for 1.14 if we really wanted.
20160729 01:42:25< iceiceice> yeah sure
20160729 01:42:29< celmin> Unless I'm wrong about the compatibility point.
20160729 01:42:39< iceiceice> i guess i dont know the details in that regard
20160729 01:42:51< iceiceice> idk if there are like 3 separate addon server instances running or just one
20160729 01:43:04< iceiceice> i guess it would make the most sense to have 3 like you are saying though
20160729 01:43:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160729 01:43:11< iceiceice> that doesn't mean that's how it actually works though :)
20160729 01:43:54< celmin> I think 1.12 and 1.13 currently have separate server instances.
20160729 01:44:00< celmin> But you'd have to ask shadowm I guess.
20160729 01:48:56< iceiceice> gnight
20160729 01:49:01-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160729 02:15:27-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 264 seconds]
20160729 02:29:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160729 02:45:18< shadowm> Yes: http://status.wesnoth.org/
20160729 03:02:03-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160729 03:03:38-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160729 03:46:07-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160729 03:49:39-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 264 seconds]
20160729 03:49:40-!- wedge010 is now known as wedge009
20160729 04:10:59< ancestral> That reminds me
20160729 04:11:23< ancestral> What’s the relationship, if any, between Wesnoth and http://www.jexiste.fr?
20160729 04:19:20< pydsigner> I've wondered that too
20160729 04:19:52< shadowm> DNS provider.
20160729 04:22:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 04:23:42< ancestral> Alright
20160729 04:24:38-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160729 04:25:58< vultraz> ok, screw these rgex errors
20160729 04:26:00< vultraz> regex
20160729 04:26:06< vultraz> I'm switching to std::
20160729 04:26:47< celmin> Oh, the linker errors, right.
20160729 04:26:49< vultraz> ancestral: been away a few hours, did you get everything working?
20160729 04:27:31< vultraz> celmin: obviously there's something wrong with either newever versions of boost, or how I've been building them
20160729 04:27:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160729 04:28:15< vultraz> all seeming to have to do with various constructs' error implementations
20160729 04:29:52< ancestral> vultraz: I got things working altering the Boost library
20160729 04:30:02< ancestral> Which is no different than Sunday. It builds, it sounds like it’s fine
20160729 04:30:36< vultraz> ancestral: can confirm the thing with removing BOOST_CONSTEXPR works
20160729 04:30:41< ancestral> I am ready to build a dev release. I suppose I was ready since Sunday
20160729 04:30:47< ancestral> vultraz: Yes, it builds removing that thing
20160729 04:30:53< ancestral> Which seems the least instrusive
20160729 04:30:56< vultraz> indeed
20160729 04:31:01< ancestral> *intrusive
20160729 04:33:25< vultraz> celmin: with what do I replace boost::regex_constants::match_not_dot_null
20160729 04:33:33< celmin> No idea!
20160729 04:33:55< celmin> I've used std::regex but never used boost::regex.
20160729 04:34:09< celmin> I don't even know what that does.
20160729 04:35:01< vultraz> "Specifies that the expression "." does not match a character null '\0'."
20160729 04:35:23< celmin> Oh fun.
20160729 04:35:36< celmin> I'd expect that to be default in the first place...
20160729 04:35:43< vultraz> maybe it is?
20160729 04:35:46< celmin> Given that null is commonly used as a string terminator.
20160729 04:35:59< celmin> (Though std::string can contain null characters just fine.)
20160729 04:37:11< vultraz> http://en.cppreference.com/w/cpp/regex/syntax_option_type
20160729 04:37:18-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160729 04:37:49< celmin> (Which is why you should always use lua_pushlstring instead of lua_pushstring when you have a std::string.)
20160729 04:38:03< vultraz> IYO, which one should be used?
20160729 04:38:20< vultraz> ECMAScript seems to be default
20160729 04:38:27< celmin> That's a good option.
20160729 04:38:33< celmin> Kinda surprised there's no PREG there.
20160729 04:38:46< celmin> But JS regexes are good enough probably.
20160729 04:38:54< celmin> (What was it using in the Boost version?)
20160729 04:39:26< vultraz> dunno
20160729 04:39:35< celmin> You should find out.
20160729 04:39:42 * vultraz signs
20160729 04:39:48< celmin> Just in case there are syntax differences.
20160729 04:39:52< vultraz> NOW it's undefined references to program_options stuff
20160729 04:39:57< vultraz> I swear to god
20160729 04:40:05< celmin> I wouldn't be surprised if Boost used PREG.
20160729 04:40:12< celmin> But I really don't know.
20160729 04:40:44< vultraz> there's obviously something wrong with boost
20160729 04:40:57< celmin> Program options… is that a lib too?
20160729 04:42:13< celmin> Do the undefined references mention C++ standard library classes?
20160729 04:42:13< celmin> For example as function arguments.
20160729 04:42:13< celmin> Or return types, or template parameters, etc.
20160729 04:42:42< vultraz> only as function argument types
20160729 04:43:03< vultraz> right now staring at a whole lot of .objs-release\src\commandline_options.o:commandline_options.cpp:(.text+0x2b90): undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)'
20160729 04:43:25< celmin> That could be a sign that Boost has been built against a different version of the C++ standard library than you are building Wesnoth against… though, hmm, that specific reference doesn't implicate anything like that...
20160729 04:45:24< vultraz> how the hell can these be present for every single library
20160729 04:45:54< celmin> ?
20160729 04:46:08< vultraz> first problems with system, then regex, now program_options
20160729 04:46:50< celmin> When you built Boost, did you use the same compiler (MinGW, right?) that you use for Wesnoth?
20160729 04:47:12< vultraz> i dunno, i just did --toolset=gcc
20160729 04:47:21< vultraz> which iirc worked for 1.58
20160729 04:47:35< celmin> It probably shouldn't matter if you used the same language standard… though I suppose it could cause problems if standard informs name mangling...
20160729 04:47:44< celmin> Okay...
20160729 04:48:07< celmin> And some of the undefined references have no mention of standard C++ library classes, eg std::string?
20160729 04:48:34< vultraz> yes
20160729 04:48:41< celmin> Seems like my idea is fruitless.
20160729 04:49:20< celmin> So you're quite sure that the libraries are being linked and that they are in the correct location for the compiler to see them...
20160729 04:49:51< celmin> Could there be a disconnect somewhere over which Boost version is being used?
20160729 04:50:02< celmin> For example, you have 1.58 headers but 1.60 libraries.
20160729 04:50:56< vultraz> nah, everything's 1.61
20160729 04:51:46< celmin> Did you do a full rebuild of Wesnoth?
20160729 04:51:50< vultraz> yes
20160729 04:52:15< celmin> Not doing that could also cause such a disconnect… but what else is there...
20160729 04:52:19< vultraz> this has happened ever since i tried using 1.60
20160729 04:52:26< vultraz> a long time ago
20160729 04:52:32< celmin> And yet it still works with 1.58?
20160729 04:52:35< vultraz> yes!
20160729 04:52:37< vultraz> always!
20160729 04:52:44< celmin> Weird...
20160729 04:52:54< vultraz> 1.6* never works
20160729 04:54:43< vultraz> the system errors only went away because i added #include <boost/system/detail/error_code.ipp>
20160729 04:54:55< vultraz> why should I need to do that!
20160729 04:55:31< celmin> That file should've been included indirectly by Boost headers.
20160729 04:56:36< vultraz> obviously
20160729 04:57:14< vultraz> but I seem to be the only dev using tdm gcc so no one else can test anything
20160729 04:57:37< celmin> tdm?
20160729 04:57:54-!- mjs-de [~mjs-de@x4e310d45.dyn.telefonica.de] has joined #wesnoth-dev
20160729 04:58:12< vultraz> yes
20160729 04:58:40< celmin> That's not the answer I was looking for.
20160729 05:02:00< vultraz> maybe i should just wait for the WSL and use gcc directly
20160729 05:02:10< celmin> WSL?
20160729 05:02:19< vultraz> Windows Subsystem for Linux
20160729 05:02:24< celmin> And tdm?
20160729 05:02:32< vultraz> what about tdm
20160729 05:02:37< celmin> What is it?
20160729 05:03:16< vultraz> http://tdm-gcc.tdragon.net/
20160729 05:04:03< celmin> …seriously, what the heck does tdm even mean… :|
20160729 05:04:09< celmin> (Rhetorical now, I guess.)
20160729 05:04:17< vultraz> I don't know
20160729 05:06:29< vultraz> but the fact that it's stuck on 5.1.0 isn't great
20160729 05:07:02< ancestral> http://stackoverflow.com/questions/28425603/what-does-tdm-stand-for-in-tdm-gcc
20160729 05:07:28< ancestral> Oooh, sounds very Wesnoth-y
20160729 05:07:38< celmin> Heh...
20160729 05:07:59< vultraz> I dunno exactly how the WSL will work
20160729 05:08:10< vultraz> but I'll see when the Anniversary Update for Win 10 comes out
20160729 05:08:36< vultraz> maybe i will mean i can kick this mingw and tdm crap to the curb
20160729 05:10:00< vultraz> there's no fix for my problems
20160729 05:10:13< vultraz> let's just wait until ancestral gets his build and then we can tag the release
20160729 05:10:46< ancestral> [11:30pm] ancestral: I am ready to build a dev release. I suppose I was ready since Sunday
20160729 05:11:47< vultraz> oh
20160729 05:11:56< vultraz> wait, can we release then?
20160729 05:12:06< celmin> Yes.
20160729 05:12:10< vultraz> blah!
20160729 05:12:12< vultraz> ok
20160729 05:12:13< celmin> As far as I know, nothing is preventing a relesae.
20160729 05:12:13< vultraz> where is loonycyborg 
20160729 05:12:15< ancestral> You tell me, release manager?
20160729 05:12:15< celmin> release
20160729 05:13:04< vultraz> i guess I can tag it
20160729 05:13:26< celmin> Make sure you do all the proper steps if you're tagging it.
20160729 05:19:36-!- irker680 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160729 05:19:36< irker680> wesnoth: Charles Dang wesnoth:master 33f33eade172 / Doxyfile changelog players_changelog src/wesconfig.h: Pre-release version bump https://github.com/wesnoth/wesnoth/commit/33f33eade17216f9dd3997ea1caa9a50984297a1
20160729 05:19:48< Aginor> *drumroll*
20160729 05:20:16< celmin> You forgot Info.plist
20160729 05:20:16< wedge009> It's happening.
20160729 05:20:27< vultraz> celmin: in xcode? it already says 1.13.5
20160729 05:20:33< celmin> Oh, right, I did that.
20160729 05:20:36< celmin> Okay, carry on.
20160729 05:23:53< irker680> wesnoth: Vultraz wesnoth: 33f33eade172 tagged as 1.13.5
20160729 05:24:36< vultraz> OK!
20160729 05:24:44< wedge009> Whee!
20160729 05:25:07< vultraz> loonycyborg, ancestral, Rhonda, whoever else needs to package things ^
20160729 05:25:23-!- vultraz changed the topic of #wesnoth-dev to: 1.13.5 tagged, announcing "soon" | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160729 05:25:43< celmin> Only really need to ping the first two.
20160729 05:25:53< celmin> BTW, there should be a ML post now, right?
20160729 05:25:57< celmin> If I recall correctly?
20160729 05:26:03< ancestral> Don’t forget the Android developer :-P
20160729 05:26:08< shadowm> vultraz: So I guess you built and uploaded the source tarballs already?
20160729 05:26:17< shadowm> And you also sent an email to all packagers?
20160729 05:26:24 * vultraz grumbles
20160729 05:26:27< celmin> That's what I'm referring to ^
20160729 05:26:30< celmin> The email
20160729 05:26:49< celmin> Source tarballs though, huh...
20160729 05:26:52< shadowm> That's not the response I was expecting.
20160729 05:26:54< vultraz> No I have not done that
20160729 05:27:04< vultraz> For one, I cannot upload to sf
20160729 05:27:20< shadowm> Okay, I am glad you thought things through as usual.
20160729 05:27:31< vultraz> I planned to relegate that to loonycyborg 
20160729 05:27:34< celmin> What exactly does building the source tarballs entail, anyway?
20160729 05:27:42< vultraz> As long as it's tagged, it doesn't matter WHO does it
20160729 05:28:09< celmin> Is it just "compress the entire git directory"?
20160729 05:28:18< celmin> (Minus .git and any untracked files, of course)
20160729 05:29:00< shadowm> I wish I had it in myself to *speak* to people like *this* with a lot of emphasis and strict requirements, like Ivanovic used to do.
20160729 05:29:59< shadowm> It's clear you know what you're doing somehow, so I'm off now.
20160729 05:30:11< vultraz> shadowm: I was reading ReleasingWesnoth
20160729 05:30:25< shadowm> Didn't read far enough apparently.
20160729 05:30:39< irker680> wesnoth: Charles Dang wesnoth:master 4c259e4a1dd2 / Doxyfile changelog players_changelog src/wesconfig.h: Post-release version bump https://github.com/wesnoth/wesnoth/commit/4c259e4a1dd2b16c6e31d1ce665552732e1f0706
20160729 05:30:57< vultraz> As I said, I plan on assigning the tarball stuff to loonycyborg 
20160729 05:31:10< celmin> Info.plist?
20160729 05:31:22< celmin> (Should that include +dev? I'm not quite sure.)
20160729 05:31:26< celmin> (Ancestral?)
20160729 05:31:32< ancestral> I think no?
20160729 05:31:37< vultraz> celmin: you decide the value for that
20160729 05:31:37< celmin> Hmm, okay.
20160729 05:32:09< ancestral> I can update the plist if you need me to?
20160729 05:32:13< vultraz> please do
20160729 05:32:30< celmin> The plist is a text file, so anyone should be able to update it.
20160729 05:32:36< shadowm> The building and testing part is supposed to save you having to retag the release if something turns out to be wrong.
20160729 05:32:54< shadowm> As well as having to rescind a previous notification to the packagers/having to do more than one of those in a row.
20160729 05:33:08< celmin> If it's supposed to have +dev in the first place.
20160729 05:33:27< celmin> Well, the ML post probably shouldn't be sent anyway if there's no source tarball uploaded, right?
20160729 05:33:28< shadowm> If you think tagging no longer requires any testing then okay.
20160729 05:33:36< celmin> But yeah, testing is important.
20160729 05:34:00< ancestral> plist is fine, like celmin said already has 1.13.5
20160729 05:34:15< celmin> No, the question is whether it should be 1.13.5+dev now.
20160729 05:34:20< ancestral> Oh
20160729 05:34:25< celmin> I'm not sure myself.
20160729 05:34:25< ancestral> Oh for master?
20160729 05:34:31< vultraz> Yes
20160729 05:34:36< ancestral> Has 1.13.5 been tagged already?
20160729 05:34:41< vultraz> Yes
20160729 05:34:43< ancestral> Okay
20160729 05:35:22< celmin> It has been tagged, but… 
20160729 05:35:49< celmin> I can't help being a little worried somehow...
20160729 05:35:54< vultraz> why?
20160729 05:36:05< celmin> Reasons.
20160729 05:36:08-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160729 05:36:59< celticminstrel> For example, did you do any testing?
20160729 05:37:28< vultraz> Earlier today everything was working fine.
20160729 05:37:39< celticminstrel> What, exactly was working fine?
20160729 05:37:49< celticminstrel> Did you try starting a game and attacking someone, for example?
20160729 05:37:49< ancestral> celticminstrel: I’m going to make some changes to the xcode project
20160729 05:37:55< celticminstrel> ancestral: Like?
20160729 05:38:16< ancestral> Notably, changing the library references from blahw.dylib to blah-mt.dylib
20160729 05:38:26< vultraz> hm, I might not have gotten that far.
20160729 05:38:39< vultraz> if there's some problem, I'll deal with it
20160729 05:38:42< ancestral> Also using latest SDK instead of 10.7 (which I don’t have)
20160729 05:38:44< vultraz> But I'm confident there won't be
20160729 05:38:54< celticminstrel> vultraz: Don't be confident. Prove it.
20160729 05:38:59< ancestral> (And for you that change shouldn’t matter, since 10.7 is the latest)
20160729 05:39:10< celticminstrel> Actually for me 10.8 is the latest.
20160729 05:39:15< celticminstrel> But it may still not matter.
20160729 05:39:36< ancestral> I’ve been told the SDK version you use shouldn’t, except in cases of PPC/Intel, which is no longer relevant to us
20160729 05:39:44< celticminstrel> Changing the Boost references is fine with me.
20160729 05:39:48< vultraz> celticminstrel: I'm switching back to 1.58 and rebuilding
20160729 05:40:21< ancestral> Oh also
20160729 05:40:29< ancestral> I have a libreadline.6.3.dylib
20160729 05:40:38< ancestral> And it was reffing a libreadline.6.dylib
20160729 05:40:46< ancestral> I can change mine, or adopt mine
20160729 05:41:06< celticminstrel> I have no idea whether changing it would work for me.
20160729 05:41:11< shadowm> I successfully buit 1.13.5 with SCons and CMake using GCC 5.4.0 and Boost 1.60.
20160729 05:41:17< ancestral> It’s the name of the library file
20160729 05:41:32< ancestral> I can either change it to what I have or change the name of my library file
20160729 05:41:36< vultraz> shadowm: it must either be a problem with my compiler or method of building, I guess
20160729 05:41:40< shadowm> The problem is I can't join the primary MP server. I get "End of file" in a popup box in the game UI after the loadscreen.
20160729 05:41:51< shadowm> Then the game refuses to respond to anything I do afterwards.
20160729 05:42:04< vultraz> shadowm: but good to know 1.60 works for you
20160729 05:42:07< celticminstrel> Well.
20160729 05:42:11< shadowm> Pressing keys, clicking on the box or the loadscreen...
20160729 05:42:27< shadowm> It reacts to Ctrl+C at least.
20160729 05:42:42< celticminstrel> :/
20160729 05:42:54< shadowm> Consider this a textbook case of bad handling of corner cases, plus bad team communication.
20160729 05:43:40< shadowm> The latter part comes from the fact that, IIRC, the game is trying to connect to an instance that's running the 1.13.4 wesnothd. IIRC loonycyborg's changes introduce some incompatibilities, so I am probably supposed to rebuild the 1.13 wesnothd so that it uses the same codebase as 1.13.5.
20160729 05:43:51< shadowm> But no-one's told me to do this yet.
20160729 05:43:56< ancestral> I can connect just fine in my build to the mp server
20160729 05:43:59< celticminstrel> Oh.
20160729 05:44:39< shadowm> (Now, if I'm remembering wrong and there are no such incompatibilities then there's clearly a problem that's not in any way my responsibility.)
20160729 05:45:09< celticminstrel> vultraz: Can you connect?
20160729 05:45:21< vultraz> celticminstrel: still building 
20160729 05:45:24< celticminstrel> Seems like ancestral can.
20160729 05:45:30< celticminstrel> I'll try too once it's built.
20160729 05:45:33< shadowm> Apparently if I click on the "End of file" box quick enough, it'll return me to the title screen.
20160729 05:45:41< shadowm> Then the game gets stuck as before too.
20160729 05:46:23< shadowm> I can hear the background music but nothing reacts to any input other than Ctrl+C (SIGINT).
20160729 05:47:01< ancestral> Say quick quetion
20160729 05:47:03< vultraz> I'll be building for another 10 minutes or so
20160729 05:47:03< ancestral> *question
20160729 05:47:06-!- mjs-de [~mjs-de@x4e310d45.dyn.telefonica.de] has quit [Remote host closed the connection]
20160729 05:47:22< ancestral> If you press : to open the console, does it leave a : in the text box?
20160729 05:47:28< celticminstrel> Yes.
20160729 05:47:34< ancestral> It seems to me that shouldn’t happen… should it?
20160729 05:47:40< celticminstrel> It shouldn't.
20160729 05:47:52< celticminstrel> But we decided it's not a blocker, so it'll be mentioned in the release notes.
20160729 05:47:56< ancestral> Yeah ok
20160729 05:48:10< celticminstrel> Maybe there should be a bug report filed though.
20160729 05:48:10 * ancestral is just doing a little testing
20160729 05:48:16< ancestral> Yes there should
20160729 05:49:05< ancestral> Interesting
20160729 05:49:20< ancestral> Lost right away
20160729 05:49:29< ancestral> Serves me right for skipping 10 levels
20160729 05:49:35< celticminstrel> ?
20160729 05:50:13< ancestral> Happened to load South Guard, skipped to 7b, defeated immediately
20160729 05:50:14< shadowm> I'm going to rebuild the dev server at the risk of breaking 1.13.4 clients, now.
20160729 05:50:24< celticminstrel> Heh.
20160729 05:50:41< ancestral> Anyway, things look good for me
20160729 05:50:47< celticminstrel> Maybe Tad's PRs will fix that, not that it's really a bug.
20160729 05:51:11< celticminstrel> I mean, there's no requirement for campaigns to remain robust in the face of debug commands like "jump to scenario".
20160729 05:51:49< shadowm> I seem able to connect to the trunk server, so that confirms the incompatibility hypothesis.
20160729 05:51:55< ancestral> Wesnoth is using 0-40% CPU, which is excellent
20160729 05:52:12< shadowm> Still, not good form to make the UI unresponsive in the event of a connection error.
20160729 05:52:23< celticminstrel> Yeah, that is indeed bad.
20160729 05:52:33< celticminstrel> Maybe it should be mentioned in release notes.
20160729 05:53:47< shadowm> Connecting to the newly rebuilt 1.13 server still gives me EOF.
20160729 05:53:56< shadowm> The plot thickens.
20160729 05:54:50< shadowm>   05:54:33 wesnoth@wesnothd:~$ readlink -e /proc/$(pidof wesnothd-1.13)/exe
20160729 05:54:51< shadowm>   /home/wesnoth/builds/wesnothd-1.13-git-1.13.5-1-g4c259e4/bin/wesnothd-1.13
20160729 05:55:03< shadowm> Pretty sure it can't be attributed to incompatibilities anymore.
20160729 05:55:22< shadowm> 1.13.5* is in versions_accepted.
20160729 05:55:46< shadowm> I'm out of ideas to diagnose this.
20160729 05:57:07< shadowm> Perhaps there's some bug involving the server-specified redirection mechanism.
20160729 05:57:31< shadowm> Since that's the only thing that could make a difference between connecting as 1.13.5 or as 1.13.5+dev.
20160729 05:58:47< shadowm> Well. I did my part and took more time than I had originally alloted for this.
20160729 06:00:56< shadowm> I've made the trunk server reject all 1.13*dev versions so you're at least forced to witness the UI unresponsiveness bug. Good night.
20160729 06:01:19< celticminstrel> That's potentially helpful.
20160729 06:03:11< vultraz> dammit, I'm getting the EoF error too
20160729 06:03:44< ancestral> Info.plist does not get +dev. That is added through some other piece of code
20160729 06:04:03< celticminstrel> ?
20160729 06:04:23< ancestral> If it’s 1.13.5 in master we’re good
20160729 06:04:35< celticminstrel> I think the Info.plist version is shown in Finder Get Info or something.
20160729 06:04:44< ancestral> Yes
20160729 06:04:50< celticminstrel> So no +dev?
20160729 06:05:04< ancestral> That happens in some other fashion
20160729 06:05:11< ancestral> It’s not defined by Info.plist
20160729 06:05:17< celticminstrel> What's not?
20160729 06:05:23< ancestral> https://github.com/wesnoth/wesnoth/commits/1.12/projectfiles/Xcode/Info.plist
20160729 06:05:32< celticminstrel> What?
20160729 06:05:41< ancestral> “+dev” does not go in that file, if that was what you were asking
20160729 06:05:57< celticminstrel> That's what I was asking, why'd you link the 1.12 version?
20160729 06:06:11< ancestral> To show a history of “+dev” not being in that file
20160729 06:06:34< celticminstrel> Anyway, if +dev does not go in that file, perhaps that should be clarified on https://wiki.wesnoth.com/ReleasingWesnoth
20160729 06:06:39 * celticminstrel hopes I typed that correctly
20160729 06:07:02< celticminstrel> I think I did already clarify that the version needs to be bumped in that file.
20160729 06:07:28< ancestral> My understansing is there’s something else that determines it’s tagged
20160729 06:07:30< celticminstrel> BTW, getting it on the app store would be hard, right?
20160729 06:07:39< ancestral> It’s like a flag or some file that sets TAGGED=true
20160729 06:08:11< celticminstrel> The game itself probably never uses that version.
20160729 06:08:13< ancestral> celticminstrel: GPL-issues aside, probably not
20160729 06:08:49< ancestral> (Never mind the “issues” part, we determined it was a non-issue)
20160729 06:08:54< celticminstrel> It probably uses the version from wesconfig or whatever.
20160729 06:09:19< celticminstrel> While Info.plist is shown by the Finder.
20160729 06:09:40< ancestral> So historically the +dev thing shows up in the title bar
20160729 06:09:42< ancestral> of the window
20160729 06:09:58< celticminstrel> Finder Get Info does not show +dev. I just checked.
20160729 06:10:08 * celticminstrel still waiting for the window to appear.
20160729 06:10:11< ancestral> If you want me to put +dev so it shows up in the Finder Get Info menu, I can. I’m just saying we’ve never done that before.
20160729 06:10:29< celticminstrel> I'm not saying I specifically want it.
20160729 06:10:46< ancestral> I’m not opposed to it. It might help people who are building identify what is what
20160729 06:11:02< ancestral> In Windows or Linux, do they have a similar convention?
20160729 06:11:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 06:11:20< celticminstrel> Not that I can think of...
20160729 06:11:41< celticminstrel> +dev is indeed in the titlebar.
20160729 06:12:06< celticminstrel> Oh right, I was going to test some other stuff too, whoops.
20160729 06:12:29< ancestral> shadowm, vultraz: FYI I tried connecting and I got the EOF message, but I did not have UI unresponsiveness.
20160729 06:13:57< celticminstrel> I got a crash.
20160729 06:14:00< celticminstrel> After moving a unit.
20160729 06:14:13< celticminstrel> Something Lua-related.
20160729 06:14:22< celticminstrel> Oh, I see.
20160729 06:14:32< celticminstrel> Not something major, at least.
20160729 06:14:54< ancestral> You got a crash moving a unit after playing a game after trying to connect to the server?
20160729 06:14:57< ancestral> ?
20160729 06:14:59< celticminstrel> The game apparently crashes on encountering an unknown ConditionalWML tag.
20160729 06:15:02< celticminstrel> No, local MP.
20160729 06:15:06< ancestral> Oh
20160729 06:15:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160729 06:16:17< vultraz> celticminstrel: it shouldn't crash, but that's not enough to retag
20160729 06:16:23< celticminstrel> Yeah.
20160729 06:16:50< celticminstrel> Trying again with that section ifdefed out.
20160729 06:17:13< celticminstrel> Whoa, attack dialogue is somehow huge.
20160729 06:17:31< celticminstrel> And poorly wrapped.
20160729 06:17:36< celticminstrel> Screenshotting.
20160729 06:17:42< celticminstrel> (Again, not worth retagging though.)
20160729 06:18:13< vultraz> cannot reproduce
20160729 06:18:20< celticminstrel> Which?
20160729 06:18:42< vultraz> an issue with the attack dialog
20160729 06:18:55< celticminstrel> It's just a layout issue.
20160729 06:19:06< ancestral> That reminds me, I never sent that email
20160729 06:19:12< celticminstrel> I get EOF and UI unresponsiveness.
20160729 06:19:28< celticminstrel> But "unresponsiveness" here means "responds slowly".
20160729 06:19:35< vultraz> I get EOF and no UI unresponsiveness
20160729 06:19:37< ancestral> Interesting, as my UI is fine
20160729 06:19:46< wedge009> For what it's worth, I also got End of File message connecting to the official server. No crash or UI problems though - just goes back to the main screen. This is on Win7.
20160729 06:19:50< celticminstrel> So if I click Quit, it quits.
20160729 06:20:06< celticminstrel> But moving my mouse around doesn't properly highlight the buttons it moves over.
20160729 06:20:16< ancestral> celticminstrel: Full screen or not?
20160729 06:20:20< celticminstrel> Not.
20160729 06:20:26< celticminstrel> I don't do fullscreen.
20160729 06:20:26< ancestral> Try toggling
20160729 06:20:29< ancestral> Sure
20160729 06:20:41< ancestral> Command + F I believe
20160729 06:20:46< celticminstrel> Furthermore I do all my testing on 800x600, because vultraz has a tendency to forget that that exists.
20160729 06:20:52< vultraz> :P
20160729 06:20:55< celticminstrel> Why are you suggesting fullscreen?
20160729 06:20:58-!- travis-ci [~travis-ci@ec2-54-163-141-219.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 06:20:59< travis-ci> wesnoth/wesnoth#9975 (1.13.5 - 33f33ea : Charles Dang): The build passed.
20160729 06:20:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148223370
20160729 06:20:59-!- travis-ci [~travis-ci@ec2-54-163-141-219.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 06:21:03< ancestral> I’m only asking as there was a bug that should have been fixed
20160729 06:21:15< ancestral> Where the buttons don’t highlight and it had to do with resolutions
20160729 06:21:22< celticminstrel> Oh.
20160729 06:21:23< ancestral> And full screen always worked, as a workaround
20160729 06:21:28< celticminstrel> No, the buttons normally do highlight.
20160729 06:21:40< ancestral> Resizing the window was another fix
20160729 06:21:49< celticminstrel> If I remain hovered over a button, I think it highlights...
20160729 06:21:57< vultraz> it looks like the EOF thing is a major issue, though
20160729 06:21:58< ancestral> Anyway, I was just curious
20160729 06:22:03< celticminstrel> (And there's no problem before the EOF.)
20160729 06:22:24< ancestral> I’d be really curious if celticminstrel gets the unresponsiveness issue with my build
20160729 06:22:37< ancestral> That would take some time, and not tonight
20160729 06:23:09< celticminstrel> Oh, this time it seems to be fine, no unresponsiveness... why...
20160729 06:23:27-!- Kwandulin [~Miranda@p200300760F606203D8EC9AED4191801D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160729 06:23:49< vultraz> we'll have to wait to loonycyborg to look at the eof thing, I guess
20160729 06:23:52< celticminstrel> The difference is that last time I'd tried a local MP game first...
20160729 06:24:10< celticminstrel> Seems like the unresponsiveness might just be temporary...
20160729 06:24:29< celticminstrel> So I guess it's probably different than shadowm's.
20160729 06:24:45< ancestral> I launched, connected to server, EOF and things are fine
20160729 06:24:46< vultraz> celticminstrel: can I see a screenshot of that attack dialog thing?
20160729 06:24:54< celticminstrel> Oh right, I was getting to that.
20160729 06:25:11< ancestral> Which reminds me
20160729 06:25:21< ancestral> I’m more than happy to work on the game theme after this release
20160729 06:25:37< ancestral> Trailer done, 1.13.5 done, then game theme
20160729 06:26:11< vultraz> celticminstrel: I guess we could merge boost_trimmings later too
20160729 06:26:33< celticminstrel> This link should work: http://celmin.pwcsite.com/wesnoth/wesnoth-attack-bad-layout.png
20160729 06:26:49 * celticminstrel hasn't verified it since Firefox is currently not open.
20160729 06:26:56 * celticminstrel uploaded with scp, whee.
20160729 06:27:04< vultraz> celticminstrel: what's the problem
20160729 06:27:16< vultraz> that's how it should look
20160729 06:27:20< celticminstrel> No, it's not.
20160729 06:27:31< vultraz> oh, I see
20160729 06:27:32< celticminstrel> The worst of it is "poison".
20160729 06:27:43< celticminstrel> But "throwing knives" possible should also be one line.
20160729 06:27:53< celticminstrel> Putting a space after the comma should fix the first issue.
20160729 06:28:30< celticminstrel> About boost_trimmings and stuff, let's wait until the base release process is complete, just in case retagging is needed.
20160729 06:29:05< celticminstrel> Hoping it won't be.
20160729 06:29:34< wedge009> Totally innocent question: What's the goal with minimising the use of boost? Not against it, just wondering what the plan is.
20160729 06:30:33< vultraz> celticminstrel: can you try characters_per_line = 30 in data/gui/window/unit_attack.cfg:236 and 272
20160729 06:30:45< celticminstrel> One moment, attempting to connect to a server.
20160729 06:30:49< ancestral> wedge009: Fewer dependencies?
20160729 06:30:54< celticminstrel> Oh.
20160729 06:31:04< ancestral> wedge009: I could be way wrong.
20160729 06:31:12< wedge009> ancestral: That's my guess (and that's a good goal) but just wanted confirmation.
20160729 06:31:13< celticminstrel> So the server crashed.
20160729 06:31:17< wedge009> O.O
20160729 06:31:37< celticminstrel> I wonder if the real server restarts in the event of a crash.
20160729 06:31:49< celticminstrel> Oh, I have unresponsiveness too now...
20160729 06:32:03< ancestral> wedge009: I was having (and still) errors with regards to STATIC_BOOST_ASSERT
20160729 06:32:12< ancestral> just as one example
20160729 06:32:12< vultraz> wedge009: well, it doesn't really reduce dependencies, but it's better to use stdlib features when possible
20160729 06:32:25< wedge009> Fair enough.
20160729 06:32:36< wedge009> ancestral: When compiling or running?
20160729 06:33:02< ancestral> Compiling
20160729 06:33:03< celticminstrel> ancestral: I thought you said you fixed it...
20160729 06:33:14< ancestral> Yes, when I make changes to the library
20160729 06:33:25< celticminstrel> Oh.
20160729 06:33:27< ancestral> But that’s not a permanent fix
20160729 06:33:32< celticminstrel> Right.
20160729 06:33:52< ancestral> We can’t just say “hey guys! when you’re building, please modify the boost library, kthx” ;-)
20160729 06:34:21< celticminstrel> It looks like my server issue now is the same thing as (or at least closely related to) the issue I was having when attempting to run the MP test.
20160729 06:35:29< celticminstrel> I have no more idea of how to fix it now than I did then...
20160729 06:35:53 * vultraz groans
20160729 06:35:58< celticminstrel> And am not sure whether it's a client-side issue (sending a bad request) or a server-side issue.
20160729 06:36:07< celticminstrel> Though I'd be more inclined to guess the latter.
20160729 06:37:52< celticminstrel> Ooh, just noticed something.
20160729 06:38:17< celticminstrel> The location of the crash is simple_wml.cpp:64, in the read call.
20160729 06:38:32< celticminstrel> The span argument to that function is a null pointer.
20160729 06:38:47< vultraz> yeah, loonycyborg will have to deal with that
20160729 06:39:05< celticminstrel> Given that it's accessed, I'm sure that can't be intended.
20160729 06:39:29< celticminstrel> So it's trying to decompress random data in memory, thus no wonder it's complaining that it's invalid gzip data.
20160729 06:40:31< celticminstrel> Ah, hmm. It's not the span itself that's a null pointer, but the str_ member of it.
20160729 06:40:59< celticminstrel> So maybe that's intended after all.
20160729 06:41:24< ancestral> celticminstrel: Your issue, does it work if you’re in fullscreen? :-P
20160729 06:41:30< celticminstrel> Which issue?
20160729 06:41:36< ancestral> The attack dialog
20160729 06:41:51< celticminstrel> Oh. No idea, don't really care since it's purely aesthetic.
20160729 06:41:58< ancestral> Of course
20160729 06:42:12< ancestral> I was confused, I thought for a moment it was crashing because of that
20160729 06:42:45< celticminstrel> So yeah, I jumped to conclusions there. The null pointer I noticed is expected and simply means the string_span is empty.
20160729 06:43:43-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds]
20160729 06:44:23< celticminstrel> The input parameter is "\x1f\x8b\b".
20160729 06:46:22< celticminstrel> This seems to be consistent... or at least, doing the same thing a second time produces the same input string_span.
20160729 06:47:04< celticminstrel> The cancel button in the waiting dialog doesn't seem to do anything.
20160729 06:47:14< celticminstrel> Even if I do manage to click it.
20160729 06:47:21< celticminstrel> Though it's also not very responsive.
20160729 06:47:32< vultraz> we should remove those dialogs on MP connect and use loadscreen stages
20160729 06:47:43< celticminstrel> It's already using the loadscreen.
20160729 06:47:53< celticminstrel> The connect dialog appears on top of that.
20160729 06:48:06< celticminstrel> So removing the connect dialog would not go amiss in my opinion.
20160729 06:48:54< vultraz> ah
20160729 06:48:58< vultraz> yeah, definitely will remove those
20160729 06:49:38< celticminstrel> Okay, I can't figure out this issue, so I'm going to bed.
20160729 06:50:15-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160729 07:00:26< irker680> wesnoth: Charles Dang wesnoth:master 32e1d2ba450b / src/units/abilities.cpp: Add space between weapon specials in list https://github.com/wesnoth/wesnoth/commit/32e1d2ba450b9874b3a9fadb91bd11027ae0d43c
20160729 07:00:29< irker680> wesnoth: Charles Dang wesnoth:master db7d94f4f4d0 / data/gui/window/unit_attack.cfg src/gui/dialogs/unit_attack.cpp: tunit_attack: few layout tweaks https://github.com/wesnoth/wesnoth/commit/db7d94f4f4d0fb79153c369ec4432d6f5c090db5
20160729 07:05:21< vultraz> ancestral: if you could purge the fixed bugs from the macOS section in the Release Notes before the announcement, that'd be great
20160729 07:05:32< ancestral> Okay
20160729 07:05:55< ancestral> Release Notes in which branch?
20160729 07:06:16< vultraz> master
20160729 07:06:17< ancestral> Or just in the file when I build
20160729 07:06:23< ancestral> Sure
20160729 07:07:20< irker680> wesnoth: Charles Dang wesnoth:master 4cd73ff5906b / RELEASE_NOTES: Clear some fixed known bugs (General and Windows) https://github.com/wesnoth/wesnoth/commit/4cd73ff5906bc9a31afbf784ee855ce7e1b37a5f
20160729 07:16:48-!- Kwandulin_2 [~Miranda@p200300760F6062039CCEC27F9335FD55.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160729 07:19:48-!- Kwandulin [~Miranda@p200300760F606203D8EC9AED4191801D.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160729 07:20:05< Rhonda> vultraz: vincent_c is the person doing most (read: all) work on the Debian side these days. :)
20160729 07:25:04< vultraz> noted
20160729 07:25:12-!- Kwandulin_2 [~Miranda@p200300760F6062039CCEC27F9335FD55.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20160729 07:29:34-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has joined #wesnoth-dev
20160729 07:30:08< vultraz> ancestral: are you planning to complete that theme overhaul for 1.14?
20160729 07:30:16< ancestral> Yes
20160729 07:33:55< ancestral> Okay, deleted about three bugs
20160729 07:36:04-!- atarocch [atarocch@nat/redhat/x-eercuizymjcuysrt] has joined #wesnoth-dev
20160729 07:36:06-!- Kwandulin [~Miranda@p200300760F606203694F3433280DC143.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160729 07:42:48< ancestral> Somehow I fscked up my git
20160729 07:52:03-!- Appleman1234 [~Appleman1@KD036012047064.au-net.ne.jp] has quit [Ping timeout: 264 seconds]
20160729 07:53:14< ancestral> vultraz: Is there a test I can do to see if monospace fonts show?
20160729 07:59:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 08:00:34-!- lipkab [~the_new_l@195.56.169.82] has joined #wesnoth-dev
20160729 08:04:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160729 08:09:28-!- JyrkiVesterinen [~JyrkiVest@87-92-30-223.bb.dnainternet.fi] has joined #wesnoth-dev
20160729 08:11:19< irker680> wesnoth: ancestral wesnoth:master f3d14a31454d / RELEASE_NOTES: Removed macOS bugs which have now been resolved. https://github.com/wesnoth/wesnoth/commit/f3d14a31454dc79c49b9d5ef484ae7605dd3dbed
20160729 08:11:37-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160729 08:23:33-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has quit [Read error: Connection reset by peer]
20160729 08:27:32-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has joined #wesnoth-dev
20160729 08:34:51< loonycyborg> vultraz: I was, like, sleeping :P
20160729 08:35:13 * Aginor frowns at wedge009 
20160729 08:44:47< Aginor> I thought I had fixed most of those flickery things, I'm obviously wrong
20160729 08:47:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160729 08:49:28-!- Appleman1234 [~Appleman1@KD036012034015.au-net.ne.jp] has joined #wesnoth-dev
20160729 08:53:01< loonycyborg> vultraz: I can repro end of file issue too
20160729 08:55:59< loonycyborg> though it's not necessarily server's fault
20160729 09:10:48-!- edgrey [~edgrey@178.204.132.64] has joined #wesnoth-dev
20160729 09:14:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 09:15:40< wedge009> Aginor: In your redo branch or master?
20160729 09:19:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160729 09:19:25-!- edgrey [~edgrey@178.204.132.64] has quit [Remote host closed the connection]
20160729 09:20:21< loonycyborg> vultraz: seems that clientside mp gui was overhauled recently
20160729 09:21:07< loonycyborg> 1.13.4 still can connect without problem
20160729 09:21:27< loonycyborg> and connection not involving redirect are fine too
20160729 09:21:42< loonycyborg> so probably clientside support for redirects got broken
20160729 09:25:06< vultraz> loonycyborg: er, clientside mp gui?
20160729 09:25:09< vultraz> which bits
20160729 09:25:35< loonycyborg> whatever part that handles redirects
20160729 09:26:21< vultraz> but I don't think there's a gui for that?
20160729 09:26:58< vultraz> anyway, can you fix this and tag 1.13.5a?
20160729 09:27:06< loonycyborg> there is gui for waiting for connection and stuff
20160729 09:27:23< vultraz> tbh, we want to remove those
20160729 09:28:22< vultraz> they're very annoying
20160729 09:29:22-!- Kwandulin [~Miranda@p200300760F606203694F3433280DC143.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160729 09:29:48< loonycyborg> anyway, it's the client's responsibility to reconnect to other server if it gets a redirect
20160729 09:30:19< loonycyborg> and it seems it just displays error message about getting disconnected instead
20160729 09:32:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160729 09:41:12< zookeeper> so what are these annoying guis that "we" want to remove now?
20160729 09:42:41< vultraz> zookeeper: those progress bars and 'wait' windows that pop up when you connect to the mp server
20160729 09:43:02< zookeeper> oh right, feedback as to what the game is doing is bad now
20160729 09:43:30< vultraz> The loading screen already says it's connecting to the server
20160729 09:45:01< zookeeper> well sure, if you want to change the dialogs to being stages of the loading screen that appears anyway then that sounds good
20160729 09:45:02< vultraz> the loading screen should be the indicator of connecting
20160729 10:06:07< loonycyborg> vultraz: https://wiki.wesnoth.org/ReleasingWesnoth#Test_the_build
20160729 10:06:19< loonycyborg> those are the things that are supposed to be done before tagging
20160729 10:06:30< loonycyborg> trying to connect to mp server is one of them
20160729 10:06:49< vultraz> Alright, we failed to test.
20160729 10:06:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160729 10:06:54< vultraz> But can you fix it :|
20160729 10:07:57< loonycyborg> I can look into it, but so far I think it's clientside issue
20160729 10:08:37< loonycyborg> so for the best result I'd need gfgtdf's help :P
20160729 10:10:59-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160729 10:11:13-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160729 10:24:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 10:28:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160729 10:38:02< Aginor> wedge009: master :/
20160729 10:38:16< Aginor> wedge009: I may have overlooked a few places
20160729 10:38:46-!- Kwandulin [~Miranda@p200300760F60623300F8B7610FE2A6CF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160729 10:39:32-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160729 10:42:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160729 10:45:29< irker680> wesnoth: loonycyborg wesnoth:master 24d0d4fe65da / src/wesnothd_connection.cpp: Fix "End of file" error if client is redirected https://github.com/wesnoth/wesnoth/commit/24d0d4fe65da2ce0d53dfc5f1ad1c91390ac1ffa
20160729 10:46:00< loonycyborg> vultraz: seems I found a fix, but I'm not 100% sure it's right one
20160729 10:46:16< loonycyborg> I'd prefer if gfgtdf reviews it too :P
20160729 10:51:30< wedge009> Aginor: I know you fixed some things related to the story map a while back but I haven't noticed any changes for a while now.
20160729 10:57:33< wedge009> loonycyborg: It works for me... has something changed on the server side? It seems to connect twice, maybe that's the redirection you referred to.
20160729 10:58:31< loonycyborg> wedge009: you're connecting to wesnoth.org?
20160729 10:58:54< wedge009> The official server, yes.
20160729 10:59:26< wedge009> Well, I presume it's going to wesnoth.org.
20160729 10:59:44< loonycyborg> when you connect to official server you actually connect to master branch server
20160729 10:59:53< loonycyborg> and then depending on client version
20160729 11:00:08< loonycyborg> it redirects you to another server of appropriate version
20160729 11:00:22< loonycyborg> so yes, that's why it would connect twice
20160729 11:00:23< wedge009> The message I get is that it's the official development MP server for 1.13.4.
20160729 11:00:35< wedge009> I don't remember it doing that before, I suppose it's relatively new.
20160729 11:01:01< loonycyborg> which branch you're at? master?
20160729 11:01:06< wedge009> master
20160729 11:01:12< loonycyborg> how new is this build?
20160729 11:01:28< loonycyborg> was it done after tagging?
20160729 11:01:34< wedge009> Built just now, straight after I saw irker say so.
20160729 11:01:40< wedge009> say you committed a fix.
20160729 11:01:56< loonycyborg> ok
20160729 11:01:57< wedge009> When I built 1.13.5 I was getting EOF message, same as everyone else.
20160729 11:02:40< loonycyborg> since vultraz did the tag and changed wesconfig.h master now works as 1.13.5 dev release\
20160729 11:02:59< loonycyborg> and it will be so until post-release version bump
20160729 11:03:00< wedge009> Yes, it is 1.13.5+dev now.
20160729 11:03:21< loonycyborg> so that's the reason you're getting a redirect now
20160729 11:03:42< loonycyborg> after post-release version bump it'll connect to master server directly, like before
20160729 11:04:45< wedge009> Which one, client or server?
20160729 11:05:02< loonycyborg> client
20160729 11:05:11< wedge009> It's possible I've never connected to 1.12 MP server before, I've never seen the lobby so full!
20160729 11:05:25< wedge009> Um, I thought the post-release bump was already done.
20160729 11:12:33-!- Duthlet [~Duthlet@dslb-178-005-055-087.178.005.pools.vodafone-ip.de] has joined #wesnoth-dev
20160729 11:16:34-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160729 11:25:24-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Read error: Connection reset by peer]
20160729 11:28:12-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20160729 11:42:40-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160729 12:12:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 12:16:27-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has left #wesnoth-dev []
20160729 12:16:32-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has joined #wesnoth-dev
20160729 12:16:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160729 12:21:11< irker680> wesnoth: Andreas Löf wesnoth:bug24553fix 15ff7e7d1a1e / src/ (events.cpp storyscreen/render.cpp): Fix bug #24553: Prevent the display (and others) from drawing over the storyscre https://github.com/wesnoth/wesnoth/commit/15ff7e7d1a1e726b0e6d03196453a7d8efc0a61c
20160729 12:24:31-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has joined #wesnoth-dev
20160729 12:28:14< Aginor> wedge009: that's a partial fix for storyscreen issues, I still need to find out about the legend of wesmere problem, that's sadly something completely different
20160729 12:33:46< wedge009> Aginor: You're up late. I was about to go to bed myself and I know you're two hours ahead of me. Not sure what's still a problem for you because the few campaigns I tried are fine - including Legend of Wesmere and Oath of Allegiance (which had the permanent-game-screen problem, not the flashing one).
20160729 12:34:33< wedge009> From my quick testing, I'd say you've fixed all cases, but if others confirm there are still problems I can double-check tomorrow.
20160729 12:34:35< Aginor> wedge009: legend of wesmere is completely black for me in the storyscreen
20160729 12:34:48< wedge009> That's what it's supposed to be, I believe. ;)
20160729 12:34:59< Aginor> oh...
20160729 12:35:06< wedge009> Kalenz' portrait doesn't come till later.
20160729 12:36:21< Aginor> ok
20160729 12:36:37< Aginor> button's are still messed up while the map is blinking though
20160729 12:36:45< irker680> wesnoth: gfgtdf wesnoth:master 8bc8efb04d71 / src/ (16 files in 9 dirs): Revert "explicitly use std::placeholders for the second std::bind parameter" https://github.com/wesnoth/wesnoth/commit/8bc8efb04d710a25409a84d5d65a3a4b0db065f1
20160729 12:36:45< irker680> wesnoth: gfgtdf wesnoth:master 6f021631e137 / src/ (18 files in 8 dirs): replace some std::bind with lambdas https://github.com/wesnoth/wesnoth/commit/6f021631e13761cee9a458fa8334d555fcfefe36
20160729 12:36:45< irker680> wesnoth: gfgtdf wesnoth:master daf7b90b725c / src/ (6 files in 3 dirs): use std::move in some places https://github.com/wesnoth/wesnoth/commit/daf7b90b725ce30893d83db0919fad7835a91156
20160729 12:36:45< irker680> wesnoth: gfgtdf wesnoth:master 36d14951c68d / src/units/unit.cpp: less config copying in unit::generate_traits https://github.com/wesnoth/wesnoth/commit/36d14951c68d370ae3d8df391c72d2ab441fa534
20160729 12:37:42< Aginor> when the flag is blinking, but not the 'x' :/
20160729 12:38:02< irker680> wesnoth: gfgtdf wesnoth:master d92c71105121 / src/game_initialization/multiplayer.cpp: fix some accidently inserted testing code. https://github.com/wesnoth/wesnoth/commit/d92c71105121cebe8de548b26db562bc753ef9af
20160729 12:40:02< Aginor> I also get this from "an orcish intrusion": 20160730 00:38:08 error display: Tile at -999,-999 isn't on the map, can't scroll to the tile.
20160729 12:40:39< Aginor> wedge009: I'll try to fix those buttons too, I'll assign the PR to you when I'm happy with it ;)
20160729 12:45:17< wedge009> Aginor: Yes, I was just checking all the campaigns again - buttons are the only things I found was a problem. Most obvious examples are Legend of Wesmere and (probably easier one to check because it happens right at the very start) Northern Rebirth. If you hover over the buttons they will appear but otherwise it's not a big deal.
20160729 12:45:47< Aginor> yeah, I should be able to fix that (I hope) :)
20160729 12:46:15< wedge009> No worries. Get some rest, I'm going to. ;)
20160729 12:46:23< Aginor> I'm about to
20160729 12:46:42< wedge009> I didn't see any output from Orcish Incursion, but I don't get the stderr in Windows.
20160729 12:46:57< wedge009> Hmm. ~runs Wesnoth from command line~
20160729 12:48:42< wedge009> Oh, it's saved in the logs now.
20160729 12:51:44< wedge009> Aginor: I do see some instances of that -999,-999 error message in the logs, but I couldn't get it from An Orcish Incursion. At least not from just stepping through the intro and the initial story conversation.
20160729 12:51:50< wedge009> No worries, leaving it for now.
20160729 12:52:32< Aginor> good night ;)
20160729 12:56:01-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 12:56:02< travis-ci> wesnoth/wesnoth#9981 (bug24553fix - 15ff7e7 : Andreas Löf): The build passed.
20160729 12:56:02< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148295131
20160729 12:56:02-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 12:57:14-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160729 12:59:28-!- JyrkiVesterinen [~JyrkiVest@87-92-30-223.bb.dnainternet.fi] has quit [Quit: .]
20160729 13:10:05-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160729 13:21:20-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160729 13:28:32-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160729 13:30:51-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160729 13:45:45-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 13:45:46< travis-ci> wesnoth/wesnoth#9983 (master - 36d1495 : gfgtdf): The build was broken.
20160729 13:45:46< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148298241
20160729 13:45:46-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 13:50:01-!- Kwandulin [~Miranda@p200300760F60623300F8B7610FE2A6CF.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160729 13:56:40-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160729 13:58:44-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160729 14:03:37< irker680> wesnoth: gfgtdf wesnoth:master 735b70ec0141 / RELEASE_NOTES: Update RELEASE_NOTES https://github.com/wesnoth/wesnoth/commit/735b70ec014115fee5b64cf4d6377be27b6e09e8
20160729 14:06:08< loonycyborg> I deleted tag vultraz made, going to try to release 24d0d4fe65da2ce0d53dfc5f1ad1c91390ac1ffa as 1.13.5
20160729 14:07:27-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160729 14:08:48-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160729 14:09:40< loonycyborg> oh wait
20160729 14:09:43< loonycyborg> no
20160729 14:09:54< loonycyborg> vultraz did post-release version bump
20160729 14:09:58< loonycyborg> hmm
20160729 14:11:22< loonycyborg> vultraz: and now what I'm supposed to do with those two version bump commits?
20160729 14:13:01-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has joined #wesnoth-dev
20160729 14:13:33< gfgtdf> loonycyborg: are the server changes that imporetant for the release? i mean it wont efect or officail server anyways and on local server there doesnt happen redirection
20160729 14:14:08< loonycyborg> bzzt wrong
20160729 14:14:29< loonycyborg> redirection happens each time the client connects to official server
20160729 14:14:44< loonycyborg> for all client versions that aren't master
20160729 14:14:47< gfgtdf> loonycyborg: yes but we ann buld our offical server indpependen on release tags
20160729 14:14:51< loonycyborg> including 1.13.5
20160729 14:15:01< gfgtdf> build*
20160729 14:15:16< loonycyborg> there are no server changes
20160729 14:15:22< loonycyborg> this was a client issue
20160729 14:15:56< loonycyborg> gfgtdf: https://github.com/wesnoth/wesnoth/commit/24d0d4fe65da2ce0d53dfc5f1ad1c91390ac1ffa
20160729 14:15:59< gfgtdf> loonycyborg: ah my bad then, sry i though thos were server changes (just red the commit message)
20160729 14:16:00< loonycyborg> that is the fix
20160729 14:16:06< loonycyborg> you should review it
20160729 14:16:29< loonycyborg> not sure if it's 100% correct
20160729 14:18:38< loonycyborg> gfgtdf: also travis seems to fail for your latest commit
20160729 14:21:12< gfgtdf> loonycyborg: my latest commit was release note update
20160729 14:21:27< gfgtdf> loonycyborg: do i doubt that it fails becasue of that.
20160729 14:21:34< loonycyborg> oh
20160729 14:21:38< loonycyborg> the one before that
20160729 14:21:54< gfgtdf> loonycyborg: the one before builed succesfully https://travis-ci.org/wesnoth/wesnoth/builds
20160729 14:22:13< gfgtdf> loonycyborg: do you have a stacktrace of when the excation was thrown before ?
20160729 14:22:20< loonycyborg> https://travis-ci.org/wesnoth/wesnoth/builds/148298241
20160729 14:22:47< vultraz> loonycyborg: just tag 1.13.5a
20160729 14:23:10< loonycyborg> gfgtdf: end of file one? given that my fix works it was thrown from the line of code I changed
20160729 14:23:28< gfgtdf> loonycyborg: y my quesiton was who called that function
20160729 14:23:45-!- Kwandulin [~Miranda@p200300760F60623381D356CF55A81505.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160729 14:23:49< loonycyborg> hmm I didn't run it under debugger
20160729 14:23:50< gfgtdf> loonycyborg: that was fixed already in another commit commit.
20160729 14:23:54< gfgtdf> loonycyborg: hm ok
20160729 14:26:10< gfgtdf> loonycyborg: are there other cases where the server slosed the connection (opposed to the client closign the connection)? If yes than i mjight be better to move the ctach to the caller that woudl most likely be this line: https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/multiplayer.cpp#L154
20160729 14:26:15< loonycyborg> vultraz: that doesn't make much sense. No need to bump version number for release that didn't happen
20160729 14:27:03< vultraz> loonycyborg: my original idea was that we leave the version number alone, leave the 1.13.5 tag, and just add a new tag (not version bump)
20160729 14:27:20< loonycyborg> I already deleted 1.13.5 tag
20160729 14:27:28< loonycyborg> now I can put it on another commit
20160729 14:27:35< vultraz> then do so.
20160729 14:27:42< loonycyborg> need to only make sure that changelogs etc still make sense
20160729 14:27:43< vultraz> leave the bump commits
20160729 14:28:27< vultraz> gfgtdf: src/game_initialization/multiplayer.cpp:147:7: error: variable ‘aaa’ set but not used [-Werror=unused-but-set-variable] is where travis failed
20160729 14:28:28< gfgtdf> you can force push to master to move the post bump to head.
20160729 14:28:36< gfgtdf> vultraz: y i know
20160729 14:28:52< gfgtdf> vultraz: was already fixced in master
20160729 14:28:58< vultraz> ok
20160729 14:37:03-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 14:37:04< travis-ci> wesnoth/wesnoth#9985 (master - 735b70e : gfgtdf): The build was fixed.
20160729 14:37:04< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148319032
20160729 14:37:04-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 14:37:20-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160729 14:44:44-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160729 14:45:00< irker680> wesnoth: loonycyborg wesnoth:master 38306057f968 / Doxyfile changelog players_changelog src/wesconfig.h: Pre-release version bump https://github.com/wesnoth/wesnoth/commit/38306057f968f206dd8fb4ec82994c48e30dcbcb
20160729 14:54:11< celticminstrel> Why were all those binds replaced by lambdas? Was it for ancestral's problems?
20160729 14:54:38< loonycyborg> If I press ; in game to get command window it inputs ; character there making me manually delete it
20160729 14:54:51< celticminstrel> This is a known bug.
20160729 15:04:25< celticminstrel> I want to fix gfgtdf's release notes... should I wait until after tagging?
20160729 15:09:48< vultraz> celticminstrel: it looks like the code is cleaner with the lambdas 
20160729 15:11:21< loonycyborg> celticminstrel: yes better wait
20160729 15:11:21< vultraz> but yeah I'd wait
20160729 15:11:24< vultraz> until after tagging
20160729 15:11:29< celticminstrel> I disagree.
20160729 15:11:32< vultraz> let's not disturb loony
20160729 15:11:39< celticminstrel> But it doesn't look less clean than before, either.
20160729 15:11:49-!- lipkab [~the_new_l@195.56.169.82] has quit [Remote host closed the connection]
20160729 15:12:31< celticminstrel> Anyway, if it wasn't for ancestral's issues, it really shouldn't've been committed at this time.
20160729 15:12:55-!- lipkab [~the_new_l@195.56.169.82] has joined #wesnoth-dev
20160729 15:13:19< celticminstrel> vultraz: When will you have the draft announcement post?
20160729 15:13:52< vultraz> celticminstrel: tomorrow
20160729 15:14:23< vultraz> is there a hurry?
20160729 15:14:44< celticminstrel> No.
20160729 15:17:11< vultraz> if not tomorrow, sunday
20160729 15:17:33< vultraz> after we have everything tagged, can you merge boost trimmings
20160729 15:17:39< celticminstrel> Huh?
20160729 15:17:46< vultraz> i'll push the regex changes manually
20160729 15:18:00< celticminstrel> Oh, never mind.
20160729 15:18:21< celticminstrel> When do you expect to push the regex changes?
20160729 15:18:52< vultraz> after you merge boost trimmings
20160729 15:18:57< vultraz> I have to redo them
20160729 15:18:59-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160729 15:19:11< vultraz> there aren't many, though
20160729 15:19:17< celticminstrel> I mean, you can push them to boost_trimmings too, if you want.
20160729 15:19:35< celticminstrel> Might be better, even.
20160729 15:19:55-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has quit [Ping timeout: 252 seconds]
20160729 15:19:59< vultraz> I was hoping to avoid two full rebuilds
20160729 15:20:15< celticminstrel> Eh?
20160729 15:21:11< vultraz> i dont have ccache
20160729 15:22:43< vultraz> so, switch to b_t, one large rebuild, then when switching back to master, then when b_t is merged
20160729 15:23:01< vultraz> if you merge b_t, then I build that, period
20160729 15:23:25< vultraz> but if it's important I'll add it to b_t
20160729 15:24:24< celticminstrel> Maybe you can avoid the second rebuild if you don't switch back to master until after it's merged.
20160729 15:25:04< celticminstrel> I don't mind merging it first though. However I would like to review the regex commit.
20160729 15:25:26< vultraz> alright
20160729 15:26:00< vultraz> i'll push it to b_t 
20160729 15:44:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 15:44:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160729 15:45:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 15:45:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160729 15:45:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 15:48:37-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160729 15:56:12-!- atarocch [atarocch@nat/redhat/x-eercuizymjcuysrt] has quit [Quit: Leaving]
20160729 15:59:51-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160729 16:02:41-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160729 16:03:09-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Client Quit]
20160729 16:03:25< celticminstrel> gfgtdf: What do you mean by "name generator syntax changes"? That's very vague, and I can't think of a relevant way in which this actually is an incompatibility.
20160729 16:03:40-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160729 16:04:08< celticminstrel> ...argh, I forgot what I wanted to say to ancestral.
20160729 16:04:20< vultraz> ancestral: can you see if master builds? bind calls were changed to lambdas
20160729 16:04:42< ancestral> Possibly over lunch
20160729 16:04:47< celticminstrel> I suspect it won't fully fix it since some of the binds I recall him having issues on were not touched.
20160729 16:05:04< celticminstrel> But I suppose it could be worth a try.
20160729 16:09:20< celticminstrel> I'm curious why the tagging is taking so long.
20160729 16:09:30< celticminstrel> Testing?
20160729 16:09:40< vultraz> he's probably doing the testing we didn't
20160729 16:10:02< irker680> wesnoth: Charles Dang wesnoth:boost_trimming 530245c05ccd / src/ (7 files in 6 dirs): Convert uses of boost::regex and related functions/types to their stdlib counter https://github.com/wesnoth/wesnoth/commit/530245c05ccd80692f49f0909cb55b67086ed807
20160729 16:10:10< vultraz> celticminstrel: ^
20160729 16:10:30< celticminstrel> vultraz: Which changelog entries under WML and Lua do you think are worth mentioning in the release notes?
20160729 16:10:53< celticminstrel> Oh right!
20160729 16:11:00< celticminstrel> ancestral: Does wesnothd run on your computer?
20160729 16:11:11< celticminstrel> And work properly?
20160729 16:11:47< celticminstrel> My build crashes, but maybe yours won't...
20160729 16:11:55< vultraz> hm
20160729 16:11:59< vultraz> I'm not sure
20160729 16:12:16< vultraz> they all seem pretty innocuous 
20160729 16:12:16< ancestral> Hosting a game local mp would test it?
20160729 16:12:50< celticminstrel> ancestral: Yeah, hosting a game and connecting to it. Or, you could switch to "wesnothd" in XCode, run, switch back to Wesnoth, run, and try to connect to localhost:15000.
20160729 16:13:00< loonycyborg> I'm building tarball I've uploaded
20160729 16:13:12< loonycyborg> and it takes forever since my cpu is kinda slow :P
20160729 16:13:15< celticminstrel> You mean uploading tarball you've built?
20160729 16:13:18< vultraz> celticminstrel: in my above commit I removed boost::regex_constants::match_not_dot_null
20160729 16:13:24< ancestral> celticminstrel: Last night it worked, but I can try over lunch
20160729 16:13:26< loonycyborg> no
20160729 16:13:26< celticminstrel> Or building tarball to upload?
20160729 16:13:33< loonycyborg> I already uploaded it\
20160729 16:13:36< loonycyborg> to both places
20160729 16:13:36< celticminstrel> ancestral: Oh, you tried it last night?
20160729 16:13:51< celticminstrel> loonycyborg: Doesn't building come before uploading? Confused.
20160729 16:13:54< loonycyborg> and decided to unpack and build it before tagging
20160729 16:14:01< ancestral> Yes, worked fine for me, hosting and playing local mp
20160729 16:14:09< loonycyborg> I built it from source dir before
20160729 16:14:15< loonycyborg> from my git checkout
20160729 16:14:16< celticminstrel> ancestral: Then that should be fine, I think.
20160729 16:14:21< vultraz> celticminstrel: so please look over it before merging
20160729 16:14:58< celticminstrel> ancestral: Also, I was thinking maybe the Mac Compile Stuff package could include bootstrap scripts that go at the toplevel and run Wesnoth from its hidden XCode location - thus allowing Mac users to attempt to run the various test scripts (and removing the need for one of my patches to run_wml_tests).
20160729 16:15:36< celticminstrel> vultraz: I never actually said it should be alright to remove it, though I think it likely is alright, but I haven't looked closely yet.
20160729 16:15:42-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160729 16:16:28< irker680> wesnoth: loonycyborg wesnoth: 38306057f968 tagged as 1.13.5
20160729 16:17:08-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160729 16:18:26< loonycyborg> now I need to mail packagers
20160729 16:18:29< celticminstrel> Hmm, actually, we should probably change the regex to also use raw strings.
20160729 16:18:53< celticminstrel> Assuming MSVC2013 supports them.
20160729 16:19:17< celticminstrel> (XCode 4 annoyingly doesn't highlight them, though my compiler does understand them.)
20160729 16:19:38-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160729 16:20:36< celticminstrel> Okay, so I was right in guessing that Boost regex defaults to Perl-style (PREG).
20160729 16:20:50< celticminstrel> So I should check if there are any important differences between that and JS-style.
20160729 16:21:02< celticminstrel> There probably aren't, but it's best to be sure.
20160729 16:22:10-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160729 16:22:19-!- lipkab [~the_new_l@195.56.169.82] has quit [Quit: Leaving]
20160729 16:22:20< vultraz> celticminstrel: oh btw after you left last night i committed a tweak to the attack dialog
20160729 16:22:27< celticminstrel> I saw.
20160729 16:22:29< vultraz> your layout issue should be better
20160729 16:23:31< Soliton> where do perl-style regex referred to as PREG?
20160729 16:23:59< celticminstrel> PREG is a C library that implements Perl-style regex, as I recall.
20160729 16:24:21< celticminstrel> Not used by Perl itself though (and is a bit different since there's no option of running Perl code from the regex).
20160729 16:24:59< celticminstrel> I was guessing that Boost.Regex depends on it, but I don't know for sure.
20160729 16:25:31< celticminstrel> Maybe it has its own implementation of Perl-style regex.
20160729 16:25:46< Soliton> maybe you're thinking of PCRE.
20160729 16:25:55< celticminstrel> Oh right.
20160729 16:26:03< celticminstrel> "preg" is from PHP.
20160729 16:26:09< celticminstrel> Sorry, got confused.
20160729 16:26:55< Soliton> i wonder why we're seemingly using regex to poorly parse WML in our code base.
20160729 16:27:13< celticminstrel> ...that's... a good question...
20160729 16:41:06< loonycyborg> what should I do in info.plist in post-release version bump?
20160729 16:41:41< celticminstrel> Uh, ancestral and I were talking about that yesterday, but I don't think we came to a conclusion...
20160729 16:42:00< celticminstrel> If you go by precedent though, it doesn't get a +dev
20160729 16:42:05< loonycyborg> should I leave it as 1.13.5 then?
20160729 16:43:28< celticminstrel> Can I push the RELEASE_NOTES fix now?
20160729 16:44:15< loonycyborg> almost
20160729 16:44:49< celticminstrel> Bundle version is a string, so I think a +dev wouldn't break anything...
20160729 16:44:51< irker680> wesnoth: loonycyborg wesnoth:master b55fc012dfd0 / Doxyfile changelog players_changelog src/wesconfig.h: Post-release version bump https://github.com/wesnoth/wesnoth/commit/b55fc012dfd0a2b0c99917ce748d1ba21d4361ba
20160729 16:44:59-!- Kwandulin [~Miranda@p200300760F60623381D356CF55A81505.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160729 16:45:16< celticminstrel> But in the past +dev has not been used in Info.plist.
20160729 16:45:28< celticminstrel> The Info.plist value will only be seen in Finder Get Info, anyway.
20160729 16:46:04< loonycyborg> when you'll reach consensus with ancestral you can change it yourself\
20160729 16:46:32< loonycyborg> anyway you can push your release notes change now
20160729 16:46:32< celticminstrel> Hmm, I just noticed that "High Resolution Capable" is set to yes in the Info.plist.
20160729 16:46:37< celticminstrel> Yeah, will do.
20160729 16:46:40< loonycyborg> only do git pull -rebase before :P
20160729 16:46:48< celticminstrel> Obviously.
20160729 16:52:51< irker680> wesnoth: Celtic Minstrel wesnoth:master 53fd31554ae8 / RELEASE_NOTES: Update RELEASE_NOTES https://github.com/wesnoth/wesnoth/commit/53fd31554ae836e0660e1b2f80ef2f0f5b47dfa9
20160729 16:52:53< irker680> wesnoth: Celtic Minstrel wesnoth:master 95c4556a59d3 / data/ai/ (14 files in 3 dirs): fai -> wfl in FormulaAI files https://github.com/wesnoth/wesnoth/commit/95c4556a59d3b677aa3597f7eabe683b88bb9941
20160729 16:55:25< celticminstrel> So I guess things can be merged starting from now.
20160729 16:55:36< celticminstrel> Like PR707 for example.
20160729 16:55:46< celticminstrel> Or Tad's role features.
20160729 16:58:59< celticminstrel> vultraz: Did you test that src/tools/schema/sourceparser.cpp still compiles?
20160729 17:01:04-!- travis-ci [~travis-ci@ec2-54-167-197-164.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 17:01:05< travis-ci> wesnoth/wesnoth#9987 (boost_trimming - 530245c : Charles Dang): The build was broken.
20160729 17:01:05< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148353560
20160729 17:01:05-!- travis-ci [~travis-ci@ec2-54-167-197-164.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 17:01:24< celticminstrel> ...what's that from?
20160729 17:05:35< celticminstrel> The regex usage in src/editor/map/map_context.cpp seems highly questionable.
20160729 17:07:17< loonycyborg> vultraz: anyway I'm done with uploading/bumping and stuff
20160729 17:07:26< vultraz> loonycyborg: sweet :)
20160729 17:07:36< vultraz> celticminstrel: looks like that particular file isn't built
20160729 17:07:40< vultraz> in my case
20160729 17:07:49< celticminstrel> vultraz: That's why I asked if you explicitly tested it.
20160729 17:08:06< vultraz> didn't
20160729 17:08:14< celticminstrel> Sigh.
20160729 17:09:25< vultraz> why is the regex use in the editor questionable?
20160729 17:09:41< celticminstrel> Because it appears to be parsing WML snippets.
20160729 17:09:45< vultraz> and where the hell is that error coming from
20160729 17:09:46< celticminstrel> Oh, right, can someone quickly check if MSVC 2013 supports raw string syntax?
20160729 17:10:00-!- Kwandulin [~Miranda@p200300760F606233354B24E7A0439300.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160729 17:10:21< celticminstrel> What's the error?
20160729 17:10:49< vultraz> undefined reference to some regex stuff in types.cpp
20160729 17:11:02< celticminstrel> Compile error, then?
20160729 17:11:19< vultraz> seems so
20160729 17:11:37< vultraz> celticminstrel: msvc2013 supports "raw string literals"
20160729 17:11:43< vultraz> is that what you meant
20160729 17:11:50< celticminstrel> Yes.
20160729 17:12:16< celticminstrel> Since I'm doing this anyway, what syntax do you prefer?
20160729 17:12:22< celticminstrel> R"""( ... )"""
20160729 17:12:31< celticminstrel> R"==( ... )=="
20160729 17:12:40< celticminstrel> or something else?
20160729 17:12:46< vultraz> uh
20160729 17:12:48< vultraz> what
20160729 17:12:49< vultraz> ?
20160729 17:12:55< celticminstrel> For raw strings.
20160729 17:13:03< vultraz> I don't even know what a raw string is
20160729 17:13:25< celticminstrel> The raw string syntax is R"<stuff>(<actual string>)<same stuff>"
20160729 17:13:25< vultraz> hm
20160729 17:13:33< vultraz> avoids using escape characters
20160729 17:13:50< vultraz> """ works I guess
20160729 17:13:51< celticminstrel> Yes, which is really good for regexes which would otherwise require double-escaping.
20160729 17:13:56< celticminstrel> Okay.
20160729 17:14:20-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20160729 17:14:22< celticminstrel> The parentheses are also not part of the string.
20160729 17:14:25< celticminstrel> Just for the record.
20160729 17:14:36< vultraz> noted
20160729 17:14:41< celticminstrel> I think the original proposal used square brackets... in fact I would have preferred that.
20160729 17:14:55< vultraz> what, R[]?
20160729 17:15:05-!- APic [apic@apic.name] has joined #wesnoth-dev
20160729 17:15:08< celticminstrel> R"stuff[...]stuff"
20160729 17:15:10< APic> B-)
20160729 17:15:21 * vultraz shrugs
20160729 17:15:23< celticminstrel> ...hi?
20160729 17:15:26< vultraz> APic: hello
20160729 17:15:27< APic> Hi.
20160729 17:15:34< vultraz> celticminstrel: so is this a change you'll be pushing soon
20160729 17:15:37< celticminstrel> Yes.
20160729 17:16:05< celticminstrel> I'm also altering the regexes that used the dot_not_null option to ensure they really don't match nulls.
20160729 17:16:54< celticminstrel> ...why is this regex escaping the forward slash character?
20160729 17:17:27< celticminstrel> Just to be sure, "[\\\\\|\\/]" reduces to a character class containing both slashes and vertical bar, right?
20160729 17:17:56< vultraz> You're asking me? :P
20160729 17:18:06< celticminstrel> No, anyone who happens to know would be fine too.
20160729 17:18:13< celticminstrel> Actually I'll also ask in another channel, why not.
20160729 17:18:26< Soliton> "[\\\\|/]" as well
20160729 17:18:37< vultraz> oh, there's someone who knows
20160729 17:18:55< celticminstrel> Ah, vertical bar doesn't need to be escaped in a charclass?
20160729 17:19:15< Soliton> not much needs to.
20160729 17:19:33< Soliton> you just have to be careful with the positioning of - and ].
20160729 17:19:50< Soliton> (if you want to match those literally.)
20160729 17:20:02< vultraz> I really can't figure out what's causing this error..
20160729 17:20:18< vultraz> I included <regex> in units/types.cpp :|
20160729 17:20:26< celticminstrel> What's the error? You never quite said.
20160729 17:21:13< vultraz> http://pastebin.com/U9CueTMu
20160729 17:22:07< celticminstrel> ...I was hoping not to have to open Firefox again until after I'd merged boost_trimming into master.
20160729 17:22:10< celticminstrel> Oh well.
20160729 17:23:10< vultraz> you really, really need a new rig :|
20160729 17:23:19 * vultraz heads to close bugs
20160729 17:23:42< celticminstrel> I suppose.
20160729 17:24:29< celticminstrel> In theory, I think installing more RAM should help, but I'm not sure if it's worth it on such an old computer that ideally would soon be replaced anyway.
20160729 17:24:37< celticminstrel> (Plus I probably can't even afford that.)
20160729 17:26:20< celticminstrel> Ah, so it's link errors.
20160729 17:27:28< celticminstrel> Works on clang without optimization, eh...
20160729 17:29:59< celticminstrel> I have an idea what might be the problem.
20160729 17:30:24< vultraz> ok, 25 bugs closed
20160729 17:30:37< celticminstrel> Oh, wait, that shouldn't be a problem...
20160729 17:30:52< celticminstrel> Hmm...
20160729 17:32:30-!- JyrkiVesterinen [~JyrkiVest@87-100-170-247.bb.dnainternet.fi] has joined #wesnoth-dev
20160729 17:35:55< vultraz> huh
20160729 17:35:58< vultraz> what is boost::get
20160729 17:36:12< celticminstrel> Tuple indexing.
20160729 17:36:29< celticminstrel> Didn't you already replace that?
20160729 17:37:18< vultraz> I replaced the tuple uses but..
20160729 17:37:21< vultraz> look at this:
20160729 17:37:23< vultraz> if ( const yes_no *p = boost::get<const yes_no>(&value_) )
20160729 17:37:27< vultraz> that doesn't seem tuple-y
20160729 17:37:28< celticminstrel> Oh, that one's for variants.
20160729 17:37:43< vultraz> does std::get apply here?
20160729 17:37:47< celticminstrel> No.
20160729 17:37:50< vultraz> ok
20160729 17:37:54-!- atarocch [~atarocch@93.56.160.28] has quit [Quit: Leaving]
20160729 17:37:59< celticminstrel> std::get takes an integer argument, that takes a type argument.
20160729 17:38:16< celticminstrel> (Template argument, not function argument.)
20160729 17:38:22< vultraz> ah, that's c++17
20160729 17:38:27< celticminstrel> Variants are?
20160729 17:38:39< vultraz> yes
20160729 17:38:47< celticminstrel> Huh, nice.
20160729 17:39:05< vultraz> c++17, continuing the quest to implement what boost did first :P
20160729 17:39:11< vultraz> (they have std::optional now too)
20160729 17:39:26< celticminstrel> Pretty sure they're using Boost as a reference.
20160729 17:39:37< celticminstrel> Though there may be subtle changes, as we've already discovered with bind.
20160729 17:40:06< celticminstrel> I wonder if Boost will ever remove any of the libraries that have become standard.
20160729 17:40:10-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has joined #wesnoth-dev
20160729 17:40:59< vultraz> is making a class non-copyable a recent thing?
20160729 17:41:13< celticminstrel> What?
20160729 17:41:21< gfgtdf> 20160729 16:03:25< celticminstrel> gfgtdf: What do you mean by "name generator syntax changes"? That's very vague, and I can't think of a relevant way in which this actually is an incompatibility.
20160729 17:41:44< vultraz> celticminstrel: https://stackoverflow.com/questions/31940886/is-there-a-stdnoncopyable-or-equivalent
20160729 17:41:57< celticminstrel> Deleted copy constructors.
20160729 17:42:09< celticminstrel> That's how you make a class non-copyable.
20160729 17:42:17< celticminstrel> Like the answer said.
20160729 17:42:24< vultraz> yes
20160729 17:42:25< gfgtdf> celticminstrel: i just adde it thjere o that it won't be forgotten in the changelog, it if fulls backwards compatible then move it to New lua/wml features i still think it shoudl be noted there though.
20160729 17:42:28< vultraz> I'm asking if it's recent
20160729 17:42:31< celticminstrel> Before C++11 you could do it by making the copy constructor private.
20160729 17:43:03< vultraz> because I'm wondering why, if there's a standard way to do it, we use boost::noncopyable so extensively
20160729 17:43:19-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160729 17:43:21< gfgtdf> s/forgotten in the changelog/forgotten in the releasenotes
20160729 17:43:21< celticminstrel> vultraz: Deleted copy constructors are new in C++11.
20160729 17:43:30< gfgtdf> there= in the release notes
20160729 17:43:51< celticminstrel> vultraz: Before that your only recourse was to make the copy constructor private and unimplemented, which isn't a perfect solution.
20160729 17:43:56< vultraz> I see
20160729 17:44:13< vultraz> so technically we could use that instead of boost::noncopyable?
20160729 17:44:16< celticminstrel> Actually, I think you can mark any function deleted if you really want to.
20160729 17:44:22< celticminstrel> I think we could, yeah.
20160729 17:44:42< vultraz> (also, 6 cases of boost::is_same still around. Can you deal with that so we don't end up stepping on each other)
20160729 17:45:27< celticminstrel> You also need to delete the copy assignment operator, by the way.
20160729 17:46:01< celticminstrel> It wouldn't hurt to keep using boost::noncopyable as it's a simple way of bundling those two requirements into a single package.
20160729 17:48:27< vultraz> celticminstrel: oh, and two cases of boost::enable_if
20160729 17:48:32< gfgtdf> celticminstrel: well those bind replacements were commited after the 1.12.5 post release bump, 
20160729 17:48:58< celticminstrel> vultraz: Which files? I might've skipped them intentionally because they're little-used files like tools.
20160729 17:49:04< gfgtdf> celticminstrel: but tzhn there was  a bug in 1.13.5 so that 1.13.5 tag was moves to  alter commit
20160729 17:49:14< vultraz> dispatcher_private.hpp
20160729 17:49:16< gfgtdf> 1.13.5*
20160729 17:49:41< vultraz> celticminstrel: that is, gui/core/event/dispatcher_private.hpp for both cases of enable_if 
20160729 17:50:14< vultraz> celticminstrel: 3 cases of is_same in that same file, and gui/auxiliary/field.hpp for the other 3
20160729 17:50:20< celticminstrel> Okay, so basically, vultraz shouldn't've done the post-release bump so soon.
20160729 17:50:22< gfgtdf> after*
20160729 17:50:31< celticminstrel> So dispatcher_private and field?
20160729 17:50:34< vultraz> yes
20160729 17:50:40< celticminstrel> I'll look.
20160729 17:51:42< vultraz> also, don't we use uint32 instead of boost::uint32_t?
20160729 17:52:19< celticminstrel> We're not very consistent there.
20160729 17:52:28< celticminstrel> SDL and <cstdint> define their own versions.
20160729 17:52:41< celticminstrel> Some other libraries do as well, I think.
20160729 17:52:46< vultraz> huh
20160729 17:52:49< celticminstrel> Not sure if we use any of them though.
20160729 17:52:55< vultraz> should we be using <cstdint>'s?
20160729 17:52:56< celticminstrel> And they don't conflict mostly.
20160729 17:53:07< celticminstrel> I'm not sure if there was a reason for using Boost's cstdint.
20160729 17:53:45< gfgtdf> celticminstrel: some compilers didn't support <cstrint> then
20160729 17:53:51< gfgtdf> <cstdint>
20160729 17:54:03< celticminstrel> gfgtdf: So the question is whether that's true of any compiler we're currently supporting.
20160729 17:54:17< gfgtdf> in particular msvc 2008 id not iirc
20160729 17:54:20< celticminstrel> So check MSVC 2013 and maybe GCC 4.7. I think they probably do, but not sure.
20160729 17:54:22< gfgtdf> did*
20160729 17:54:30< gfgtdf> msvc 2010 does
20160729 17:54:35< celticminstrel> Okay.
20160729 17:54:49< celticminstrel> In that case we can stop using Boost's version.
20160729 17:54:57< vultraz> celticminstrel: oh, and could you also take care of the one case of boost::cref in gui/dialogs/lobby/lobby.cpp:424
20160729 17:55:02< celticminstrel> (Assuming GCC 4.7 does, but I'd be surprised if it didn't.)
20160729 17:55:40< vultraz> celticminstrel: actually, if you haven't committed anything I could deal with these
20160729 17:55:43< vultraz> or would you prefer to
20160729 17:55:51< celticminstrel> I was just about to commit the raw-strings.
20160729 17:55:59< vultraz> ok, I'll leave you to it
20160729 17:56:51-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160729 18:08:14< celticminstrel> Happened across an MSVC 2008 workaround.
20160729 18:08:52< vultraz> I thought I removed them all
20160729 18:08:58< vultraz> unless you mean the >=1600?
20160729 18:09:10< celticminstrel> It wasn't behind a preprocessor directive.
20160729 18:09:43< vultraz> oh
20160729 18:09:45< vultraz> please remove
20160729 18:10:22< celticminstrel> What's the year for MSVC 9? Grep shows there's a workaround for MSVC 9 in side_filter.hpp.
20160729 18:11:06< celticminstrel> I think I'll ignore that one for now.
20160729 18:11:08< vultraz> 2008
20160729 18:11:15< celticminstrel> Oh? Maybe I won't then.
20160729 18:12:01< celticminstrel> Hmm, it's behind an ifdef, but there's no version check.
20160729 18:12:13 * celticminstrel pings JyrkiVesterinen 
20160729 18:12:43< JyrkiVesterinen> celticminstrel: What is it?
20160729 18:12:57< celticminstrel> The default constructor in side_filter, is that needed?
20160729 18:13:03< celticminstrel> ie, does it compile without.
20160729 18:14:02< celticminstrel> Oh, terrain filter (src/terrain/filter.hpp) also has this.
20160729 18:14:26< celticminstrel> Same question there.
20160729 18:14:49< JyrkiVesterinen> Checking now, with both defaults constructors removed.
20160729 18:15:14< JyrkiVesterinen> (Probably takes some time to rebuild. They are both header files, and my filesystem cache is cold.)
20160729 18:21:45-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160729 18:21:52< Kwandulin> vultraz: regarding the story art specifications, I think you should mention the px resolution. Do you want 1280x720 or 1366x768 or anything else?
20160729 18:23:02< vultraz> Kwandulin: higher the better, as long as it's either 16:9 (recommended) or 4:3. 
20160729 18:23:59< JyrkiVesterinen> celticminstrel: Build succeeded with the default constructors removed.
20160729 18:24:12< celticminstrel> Yay.
20160729 18:28:51< celmin> Apparently sourceparser.cpp is included in the XCode build, for some reason.
20160729 18:30:47< vultraz> is uint32 different from unit32_t?
20160729 18:30:53< celmin> No
20160729 18:31:05< celmin> I assume you mean uint not unit though
20160729 18:31:10< vultraz> right
20160729 18:31:44< irker680> wesnoth: Charles Dang wesnoth:boost_trimming 14db37d7faea / src/ (7 files in 6 dirs): Convert uses of boost::regex and related functions/types to their stdlib counter https://github.com/wesnoth/wesnoth/commit/14db37d7faea4ee12c162350a4bcc270c043417d
20160729 18:31:47< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming c3dd55e057d4 / src/ (4 files in 4 dirs): Use raw string literals for regex https://github.com/wesnoth/wesnoth/commit/c3dd55e057d4c5d53e23fb69906018a92f895085
20160729 18:31:49< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming dd5dc317e783 / src/gui/ (auxiliary/field.hpp core/event/dispatcher_private.hpp): Remove a few more uses of Boost type traits and enable_if https://github.com/wesnoth/wesnoth/commit/dd5dc317e7838ebc9998d811eaf7df658809d3fd
20160729 18:31:51< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming 9196d338e0a6 / src/ (config.cpp gui/dialogs/lobby/lobby.cpp server/server.cpp): Remove some instances of boost::ref https://github.com/wesnoth/wesnoth/commit/9196d338e0a6c21c278786e8d9df8283d2d24629
20160729 18:31:53< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming b9a21301706d / src/ (4 files in 3 dirs): Remove a couple more MSVC 2008 workarounds https://github.com/wesnoth/wesnoth/commit/b9a21301706d9099ee636df0597e0b2618de2408
20160729 18:33:45< vultraz> so what did you change in my commit>
20160729 18:33:46< vultraz> ?
20160729 18:34:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160729 18:34:33< JyrkiVesterinen> celticminstrel: Uh, you need to remove the definitions of the default constructors as well.
20160729 18:34:44< celmin> Oh, right.
20160729 18:35:45 * vultraz waits for commit
20160729 18:35:58< vultraz> then I'll work on the uint32 thing
20160729 18:36:37< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming 42bec4fdc9de / src/ (6 files in 3 dirs): Remove a couple more MSVC 2008 workarounds https://github.com/wesnoth/wesnoth/commit/42bec4fdc9de90b3bd409c08495d33f05f0f01c0
20160729 18:37:20< vultraz> oh
20160729 18:37:25< celmin> Hm?
20160729 18:37:28< vultraz> celticminstrel: should this be closed? https://gna.org/bugs/?24697
20160729 18:38:49< celmin> ...weird.
20160729 18:38:59< celmin> Wonder what the WML of that unit looks like.
20160729 18:39:30< celmin> (Unrelatedly, why is there a succubus in the vampire faction? That makes no sense whatsoever.)
20160729 18:44:57< vultraz> huh
20160729 18:45:18< vultraz> my compiler is complaining about Uint32 :|
20160729 18:46:12< celmin> That's from SDL_types.h
20160729 18:47:07< vultraz> oh
20160729 18:47:26< vultraz> so is the cstdint one unit32_t?
20160729 18:47:42< celmin> Yeah
20160729 18:47:50< vultraz> ahhh
20160729 18:47:56< vultraz> t'is confusing
20160729 18:55:57< vultraz> you build the tests, right?
20160729 18:57:26< vultraz> celticminstrel: in serialization/unicode_types.hpp:24 I should be able to remove that typedef, right?
20160729 18:58:25< celmin> The first one, sure.
20160729 18:58:41< celmin> Or maybe better to just change it to the standard instead of boost.
20160729 18:58:58< vultraz> obv
20160729 18:59:43-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 18:59:44< travis-ci> wesnoth/wesnoth#9991 (boost_trimming - b9a2130 : Celtic Minstrel): The build has errored.
20160729 18:59:44< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148389592
20160729 18:59:44-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 19:00:28< vultraz> what the hell is with that file and typdefing everything
20160729 19:00:52< celmin> Maybe there's good reasons, I dunno.
20160729 19:01:02< vultraz> maybe I'll leave those typedefs alone
20160729 19:01:16< vultraz> still will make it standard unit32_t, though
20160729 19:04:31-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160729 19:13:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160729 19:18:02< irker680> wesnoth: Charles Dang wesnoth:boost_trimming ae2ccb34dea0 / src/ (38 files in 10 dirs): Convert uses of boost integer types to their stdlib equivalents https://github.com/wesnoth/wesnoth/commit/ae2ccb34dea0b3dd5a41529cc171e63ce400811a
20160729 19:18:04< vultraz> celticminstrel: ^
20160729 19:19:04< vultraz> hm. probably could've removed the include in seed_rng.hpp altogether 
20160729 19:19:23< vultraz> didn't know about neon.hpp
20160729 19:20:23< celmin> Might need to add more <cstdint> but we'll leave that for the people who need it (if they exist).
20160729 19:20:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160729 19:22:03< vultraz> I'll leave the one in neon.hpp since I don't understand that file
20160729 19:23:03< vultraz> oh, the one in seed_rng is needed
20160729 19:23:05< vultraz> ok
20160729 19:23:08< vultraz> looks like the commit is fine
20160729 19:24:28< vultraz> I think we're about done
20160729 19:25:07< vultraz> still a few cases of boost::assign::list_of that could maybe converted to initializer lists, not sure.
20160729 19:25:40< vultraz> not sure what exactly boost::assign::list_of().convert_to_container<> does
20160729 19:25:55< celmin> Same thing.
20160729 19:26:11< celmin> But for types other than (presumably) vector.
20160729 19:26:38< vultraz> let's see what the usescases are..
20160729 19:26:45< vultraz> convert_to_container<std::vector<config> >()
20160729 19:26:55< vultraz> convert_to_container<std::list<config> >()
20160729 19:27:22< vultraz> convert_to_container<stringset>() (stringset is boost::container::flat_set<std::string>)
20160729 19:27:39< vultraz> another one like that...
20160729 19:34:29< vultraz> seems most of these work with initilizer lists
20160729 19:37:58-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 19:37:59< travis-ci> wesnoth/wesnoth#9992 (boost_trimming - 42bec4f : Celtic Minstrel): The build is still failing.
20160729 19:37:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148391200
20160729 19:37:59-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 19:40:24-!- Kwandulin [~Miranda@p200300760F606233354B24E7A0439300.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160729 19:45:03< irker680> wesnoth: Charles Dang wesnoth:boost_trimming c31ffa22a7a0 / src/ (7 files in 3 dirs): Use initializer lists in place of remaining boost::asign::list_of cases https://github.com/wesnoth/wesnoth/commit/c31ffa22a7a010daa924e4155bf460961f271184
20160729 19:45:06< irker680> wesnoth: Charles Dang wesnoth:boost_trimming b9662bf2f7ed / src/tools/sdl2/window.cpp: Convert remaining boost::lexical_cast cases to our own implementation (extension https://github.com/wesnoth/wesnoth/commit/b9662bf2f7ed38b447c21114f24107dd67fc45a8
20160729 19:47:09< celmin> Theoretically make_pair could be eliminated in test_map_location.cpp, but I think my compiler version has a bug there.
20160729 19:47:28< celmin> So I guess it's fine to leave it.
20160729 19:48:16< vultraz> hm.. two cases of boost::assign::map_list_of
20160729 19:48:20< vultraz> I wonder how that's different
20160729 19:48:24< vultraz> than list_of
20160729 19:48:29< vultraz> from*
20160729 19:48:36< celmin> Pretty much the same.
20160729 19:48:50< celmin> I'll change those due to the aforementioned bug.
20160729 19:49:47-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160729 19:50:38< vultraz> does that mean string_map_of isn't needed?
20160729 19:51:03< vultraz> also, travis is still failing on the regex thing
20160729 19:51:49< celmin> Not sure why.
20160729 19:52:13< irker680> wesnoth: Charles Dang wesnoth:boost_trimming 7f563da22f02 / src/ (4 files in 3 dirs): Include cleanup from c31ffa22a7a0 https://github.com/wesnoth/wesnoth/commit/7f563da22f02e697953b48cb0ca470a97702a07d
20160729 19:52:17< vultraz> I'll squash that later ^
20160729 19:52:51< mattsc> does #ifver not work inside macros?
20160729 19:53:45< vultraz> WML or C++?
20160729 19:53:48< celmin> WML, duh
20160729 19:53:54< celmin> There's no such thing in C++
20160729 19:54:01< vultraz> right
20160729 19:54:03< vultraz> duh
20160729 19:54:04< vultraz> it should
20160729 19:54:16< celmin> I really have no idea.
20160729 19:54:33< mattsc> celmin: I am trying to do this: http://pastebin.com/QAPgWWyg
20160729 19:54:54< mattsc> If I remove the #ifver and the “old” syntax, it works just fine
20160729 19:55:07< celmin> I see.
20160729 19:55:13< mattsc> when I have it like that, the [args] in the side is empty
20160729 19:55:21< mattsc> in current master
20160729 19:55:29< mattsc> any idea what I might be doing wrong?
20160729 19:56:22< celmin> It sounds like preprocessor directives just don't work inside macro substitutions. You could define the [args] in a submacro and undef it right after.
20160729 19:57:49< zookeeper> there's lots of macros which are fed ActionWML or otherwise long pieces of WML as arguments, i'd think it'd have been noticed if some preprocessor stuff in general didn't work there
20160729 19:58:21< zookeeper> but, uh, i don't know.
20160729 19:59:26< mattsc> well, additional test point:
20160729 19:59:46< mattsc> If I move the entire [ai] tag into the #ifver, it works again
20160729 20:00:08< mattsc> so yes, it must be somethign like the interaction between that macro and the ifver
20160729 20:00:57< mattsc> I’ll do it differently then …
20160729 20:01:26< vultraz> celmin: are you planning on pushing a commit that changes string_utils.hpp
20160729 20:01:31< celmin> Yes.
20160729 20:01:31< vultraz> I have a commit here that changes it
20160729 20:01:35< celmin> What does it change?
20160729 20:01:40< vultraz> boost::next -> std::next
20160729 20:01:52< celmin> Oh, I was doing that, I'll revert it then.
20160729 20:02:03< celmin> I only did it because I happened to notice it
20160729 20:02:08< zookeeper> weird. although, i seem to recall that there's _some_ preprocessor-related things you can't do inside macro arguments...
20160729 20:03:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 20:03:22< vultraz> celmin: if you did it I'll let you commit
20160729 20:03:24< vultraz> easier that way
20160729 20:03:32< celmin> I'd just started.
20160729 20:03:53< celmin> If you've already committed I think it's easier to just accept that.
20160729 20:04:54< vultraz> alright
20160729 20:05:09< vultraz> ill let my build finish tho
20160729 20:06:59-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160729 20:17:25< irker680> wesnoth: Charles Dang wesnoth:boost_trimming 8ec544eedde5 / src/ (serialization/string_utils.hpp server/server.cpp): Convert cases of boost::next to std::next https://github.com/wesnoth/wesnoth/commit/8ec544eedde523a143e87a67371e2ee5818abd9d
20160729 20:17:45< vultraz> celticminstrel: ^
20160729 20:18:42< vultraz> still 6 cases of boost::copy too but those might have to stay since they use boost adapters 
20160729 20:19:49-!- travis-ci [~travis-ci@ec2-54-167-197-164.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 20:19:50< travis-ci> wesnoth/wesnoth#9993 (boost_trimming - ae2ccb3 : Charles Dang): The build failed.
20160729 20:19:50< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148403770
20160729 20:19:50-!- travis-ci [~travis-ci@ec2-54-167-197-164.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 20:23:19< celmin> vultraz: What about your squash>
20160729 20:23:25< celmin> ^?
20160729 20:23:47< vultraz> was going to do it after you pushed your commit
20160729 20:23:52< celmin> The cases of boost::copy could be converted, but it's non-trivial (as you can see by the one instance that was already converted) and probably not worth it.
20160729 20:23:57< celmin> Ah, I guess that's okay.
20160729 20:24:11< celmin> Was there any other Boost stuff you were working on?
20160729 20:24:20< vultraz> not right now
20160729 20:27:40< celmin> (boost::copy is actually probably slightly more efficient than the std way of doing the same thing, as it should avoid temporary containers.)
20160729 20:29:12< vultraz> ah, boost::array -> std::array
20160729 20:31:11< vultraz> er
20160729 20:31:12< vultraz> hm
20160729 20:31:22< vultraz> .assign... what's the equivalent of .assign..
20160729 20:31:31< celmin> I got boost::array.
20160729 20:31:36< vultraz> ah
20160729 20:31:38< vultraz> nvm then
20160729 20:31:51< celmin> The assign turned into a fill, I think, though not quite sure if std has that.
20160729 20:32:04< celmin> If not I can use the algorithm version.
20160729 20:32:33< vultraz> std:;array has fill
20160729 20:32:54< mattsc> Ooo, I got my AI test scenario to cause an assertion failure at synced_context.cpp, line 288
20160729 20:33:54< mattsc> I’ll check out some other time what that’s all about.
20160729 20:34:23< celmin> I got a couple of other Boost things too.
20160729 20:38:48-!- travis-ci [~travis-ci@ec2-54-167-197-164.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 20:38:49< travis-ci> wesnoth/wesnoth#9994 (boost_trimming - b9662bf : Charles Dang): The build is still failing.
20160729 20:38:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148410329
20160729 20:38:49-!- travis-ci [~travis-ci@ec2-54-167-197-164.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 20:41:31< mattsc> celmin: how do I get access to the ai table in player-controlled mode now in master?
20160729 20:41:42< celmin> debug_ai?
20160729 20:41:42< mattsc> previously I could do ‘local ai = wesnoth.debug_ai(wesnoth.current.side).ai’, but that does not seem to work any more
20160729 20:41:48< celmin> It's supposed to.
20160729 20:41:50< celmin> Oh right.
20160729 20:42:03< celmin> You do need debug mode enabled.
20160729 20:42:14< mattsc> I have; I almost always do.
20160729 20:42:17< celmin> Okay.
20160729 20:42:36< celmin> So, what makes you believe that that does not work?
20160729 20:42:44< mattsc> All it gives me is a table that contains read_only = false
20160729 20:43:00< mattsc> Looking at it with dbms()
20160729 20:43:05< celmin> That's correct.
20160729 20:43:16< mattsc> Also, it complains that I cannot move a unit when I try.
20160729 20:43:18< celmin> The other things are there, but won't show up in dbms.
20160729 20:43:39< celmin> Unless something went wrong.
20160729 20:44:14< mattsc> Hmm, let me try something else
20160729 20:44:24< celmin> Can you access check_move?
20160729 20:45:18< mattsc> Uh, hmm, no it does work ...
20160729 20:45:50< mattsc> When I call it directly, rather than through a CA execution function, which is what I tired previously.
20160729 20:46:08< mattsc> So I must be passing the table around incorrectly somehow.
20160729 20:46:11< mattsc> My bad, sorry.
20160729 20:46:17-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160729 20:46:19< celmin> Okay then
20160729 20:54:52< vultraz> celmin: what about boost::unordered_map?
20160729 20:55:12< celmin> Currently having a problem with that, but I think I know how to fix it.
20160729 21:07:05-!- JyrkiVesterinen [~JyrkiVest@87-100-170-247.bb.dnainternet.fi] has quit [Quit: Going to bed]
20160729 21:10:47-!- travis-ci [~travis-ci@ec2-54-167-197-164.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 21:10:48< travis-ci> wesnoth/wesnoth#9995 (boost_trimming - 7f563da : Charles Dang): The build is still failing.
20160729 21:10:48< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148412251
20160729 21:10:48-!- travis-ci [~travis-ci@ec2-54-167-197-164.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 21:13:05-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160729 21:15:19< vultraz> celmin: are copy constructors supposed to be public or private? does it even matter if you delete them?
20160729 21:15:27< celmin> ...
20160729 21:15:52< celmin> If you want the class to be copyable, obviously the copy constructor needs to be public.
20160729 21:16:04< vultraz> ok, that's what I thought
20160729 21:28:27-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 21:28:28< travis-ci> wesnoth/wesnoth#9996 (boost_trimming - 8ec544e : Charles Dang): The build is still failing.
20160729 21:28:28< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148418763
20160729 21:28:28-!- travis-ci [~travis-ci@ec2-54-159-60-39.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 21:31:15< bumbadadabum> is there a C++/lua thing I could work on
20160729 21:31:28< bumbadadabum> otherwise I might get back to my EI overhaul thing
20160729 21:32:03< vultraz> I thought you didn't want to do c++
20160729 21:39:06-!- ancestral [~ancestral@96.93.236.121] has joined #wesnoth-dev
20160729 21:40:09< vultraz> ah, ancestral!
20160729 21:40:20< vultraz> wait, why did I want you again
20160729 21:40:22< vultraz> oh right
20160729 21:40:32< vultraz> ancestral: the gamestate inspector and lua consoles should use monospace fonts
20160729 21:40:58< ancestral> How do I activate that?
20160729 21:41:03< vultraz> `
20160729 21:41:09< ancestral> Okay
20160729 21:41:57< ancestral> Is that where you type in commands?
20160729 21:42:13< vultraz> no just press the ` key
20160729 21:42:18< vultraz> in debug mode, of course
20160729 21:42:30< vultraz> that will give you the lua console
20160729 21:42:32< ancestral> That should be monospace?
20160729 21:42:37< vultraz> you can even do that from the titlescreen
20160729 21:42:40< vultraz> yes
20160729 21:42:59< ancestral> I can’t from the titlescreen
20160729 21:43:12< vultraz> you need to be in debug mode
20160729 21:43:41< ancestral> Okay, so I entered debug mode
20160729 21:43:56< ancestral> But I press ` or : from the title screen and nothing happens
20160729 21:44:10< vultraz> hm
20160729 21:44:21< vultraz> btw the command key is now ; not :
20160729 21:44:22< vultraz> js
20160729 21:44:29< ancestral> Sure ; I mean
20160729 21:44:32< vultraz> but *that* doesn't work from the titlescreen
20160729 21:44:35< ancestral> Anyway, no bog deal
20160729 21:44:39< vultraz> anyway, just go in-game then and do ;inspect
20160729 21:44:42< vultraz> that should also be monospace
20160729 21:44:45< ancestral> inspect ok
20160729 21:44:55< vultraz> the text area that is, not the list of items
20160729 21:45:26< ancestral> Okay so the text in inspect is monospace
20160729 21:45:30-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160729 21:45:43< vultraz> there's a button there to launch the lua console too
20160729 21:45:45< ancestral> But the text in the textbox for the console is not
20160729 21:45:49< ancestral> Hmm
20160729 21:45:59< ancestral> Okay that is monospace too
20160729 21:46:31< ancestral> Should the textbox for the console? the textbox enabled by pressing ; or ` be monospace?
20160729 21:46:38< vultraz> the only thing that's supposed to be monospace is the output
20160729 21:46:41< vultraz> not where you type
20160729 21:46:49< bumbadadabum> <vultraz> I thought you didn't want to do c++ <-- but then I did the trait thing anyway
20160729 21:46:56< vultraz> ancestral: no
20160729 21:47:20< vultraz> bumbadadabum: plz merge
20160729 21:47:27< celmin> Wait a second.
20160729 21:47:43-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has joined #wesnoth-dev
20160729 21:47:52< vultraz> bumbadadabum: do not merge
20160729 21:48:06< gfgtdf> 20160729 20:31:22< vultraz> .assign... what's the equivalent of .assign..
20160729 21:48:07< celmin> Just checking it quickly.
20160729 21:48:18< gfgtdf> vultraz: the c++ silution are most likely initilizer lists
20160729 21:48:21< celmin> gfgtdf: That was resolved.
20160729 21:48:28< celmin> gfgtdf: It's nothing to do with initializer lists.
20160729 21:48:38< celmin> gfgtdf: It was boost::array::assign
20160729 21:48:48< gfgtdf> celmin: you were not taling about boost::assigm ?
20160729 21:48:55< celmin> Not in that instance, no.
20160729 21:48:56< gfgtdf> boost/assign i meant
20160729 21:49:03< celmin> We were talking about it before that though.
20160729 21:49:06< vultraz> ancestral: I think that means this is fixed? https://gna.org/bugs/?23628
20160729 21:49:27< vultraz> even though we're not using DVS anymore
20160729 21:49:37< ancestral> vultraz: Okay Yes
20160729 21:49:44< celmin> Okay, still uncertain about showing availability i the trait, but I guess it can be merged. Shall I merge the PR or leave it to bumbadadabum?
20160729 21:50:02< vultraz> ancestral: and I think that's another item off the known bugs list :)
20160729 21:50:13< vultraz> celmin: let bumbadadabum do it
20160729 21:50:18< bumbadadabum> celmin: I want to update the changelog in the commit
20160729 21:50:18< gfgtdf> 20160729 21:31:15< bumbadadabum> is there a C++/lua thing I could work on
20160729 21:50:38< gfgtdf> bumbadadabum: didt i list multiple c++ things recently or was i takling to someone else  ?
20160729 21:51:06< vultraz> ancestral: I think https://gna.org/bugs/?23559 and https://gna.org/bugs/?23560 can also be closed
20160729 21:51:18< gfgtdf> bumbadadabum: ruigth was talikng to lipkab
20160729 21:51:27< celmin> bumbadadabum: Okay, go ahead and do that, and then merge it.
20160729 21:51:43< celmin> gfgtdf: You were probably talking to lipkab?
20160729 21:51:51< celmin> I remember listing some things for him too.
20160729 21:52:33< vultraz> yes
20160729 21:52:36< vultraz> it was lipkab
20160729 21:52:36< celmin> Looks like I've got the unordered_map issue dealt with.
20160729 21:52:44< vultraz> sweet :D
20160729 21:52:47< vultraz> commits coming soon?
20160729 21:52:59< celmin> I'll push all this stuff in a few minutes, then if it builds for you I guess you could merge it.
20160729 21:53:15< vultraz> what about travis and the regex thing?
20160729 21:53:25< celmin> Oh right.
20160729 21:53:38< celmin> I'm not sure what to do with that. One of the builds does succeed.
20160729 21:53:55< celmin> But the GCC build and the optimized clang build fail.
20160729 21:54:24< vultraz> bumbadadabum: https://gna.org/bugs/?23287
20160729 21:54:39< vultraz> bumbadadabum: that should be simple
20160729 21:55:11< celmin> That's not directly related to the topic generation though.
20160729 21:55:20< celmin> But yeah, should be simple
20160729 21:55:22< bumbadadabum> ok I'll do that
20160729 21:55:29< vultraz> bumbadadabum: or a very very good thing you could do: make it so [message] doesn't make the screen scroll if the next speaker is on screen and outside, say, 5 hexes of the edges.
20160729 21:55:37< celmin> Might actually be in game_lua_kernel.cpp now...
20160729 21:56:05< celmin> [message] is in Lua, though that might require some C++ coding if there's no API for something you need,
20160729 21:58:32-!- mjs-de [~mjs-de@x4e3157fd.dyn.telefonica.de] has joined #wesnoth-dev
20160729 22:00:52< ancestral> celmin: Have you tried (or do you know how) to enable OpenMP support, or how one does that?
20160729 22:00:57< ancestral> for OS X
20160729 22:01:07< celmin> Haven't tried, don't know how, don't even know what it is.
20160729 22:01:25< ancestral> I only know vaguely; bug 18144
20160729 22:02:34< vultraz> I build with it, but im not on macos
20160729 22:02:59< celmin> I think there was a problem with it on MacOS.
20160729 22:05:09< ancestral> vultraz: Do you know what file says build with it?
20160729 22:05:15< ancestral> celmin: Right, I want to test with it now
20160729 22:05:16< vultraz> I do not
20160729 22:05:34< celmin> Is there a preprocessor define?
20160729 22:05:41< celmin> BTW, what is OpenMP?
20160729 22:05:54< vultraz> there's a bunch of #ifdef _OPENMP guards in a few files
20160729 22:06:23< vultraz> celmin: "An API for multi-platform shared-memory parallel programming in C/C++ and Fortran"
20160729 22:06:29< vultraz> whatever that means
20160729 22:06:43-!- ancestral [~ancestral@96.93.236.121] has quit [Quit: i go nstuf kthxbai]
20160729 22:06:48< celmin> So what has it got to do with Wesnoth?
20160729 22:06:58 * vultraz shrugs
20160729 22:07:40< vultraz> there's barely any code associated with it
20160729 22:09:40< vultraz> all of which seems to be a small block in wesnoth.cpp
20160729 22:09:43< vultraz> honestly
20160729 22:09:46< vultraz> I'd say remove it
20160729 22:10:33< vultraz> I mean, that code is even only used on msvc anyway..
20160729 22:10:59< vultraz> ok, seriously
20160729 22:11:03< vultraz> is there ANY code that uses this?
20160729 22:11:08< celmin> I think someone voting to remove it should at least understand what it is and what it's for.
20160729 22:11:23< celmin> Who introduced it?
20160729 22:11:54< vultraz> no idea
20160729 22:11:58< vultraz> it's been here for years
20160729 22:12:07< vultraz> ok, there's a small bit of code in display.cpp
20160729 22:12:46-!- iceiceice [~chris@50.245.222.235] has joined #wesnoth-dev
20160729 22:12:46-!- iceiceice [~chris@50.245.222.235] has quit [Changing host]
20160729 22:12:46-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160729 22:13:06< iceiceice> vultraz, OpenMP is a parallelization framework
20160729 22:13:08< vultraz> and then some code in wesnoth.cpp that's only used if _MSC_VER >= 1600
20160729 22:13:12< iceiceice> it is part of GCC
20160729 22:13:28< iceiceice> some defines were added to it at one point
20160729 22:13:30< iceiceice> to try to accelerate our graphics
20160729 22:13:46< iceiceice> i remember that i messed it up one time when i changed part of the display code
20160729 22:13:56< iceiceice> and then aquileia complained that some windows builds were broken
20160729 22:14:00< iceiceice> and figured out how to fix it
20160729 22:14:00< vultraz> to accelerate our graphics?
20160729 22:14:04< iceiceice> yes
20160729 22:14:16< vultraz> well that sounds like entirely the wrong way to do something like this..
20160729 22:14:24< iceiceice> well its what we had for years
20160729 22:14:28< iceiceice> idk i mean
20160729 22:14:28< vultraz> did it work?
20160729 22:14:41< iceiceice> i dont know, i think it was only enabled for windows builds
20160729 22:14:49< iceiceice> idk if loonycyborg actually uses it
20160729 22:15:03< iceiceice> its kind of mysterious to me to be honest
20160729 22:15:08< iceiceice> it was something like
20160729 22:15:12< iceiceice> there were a bunch of pragmas or something
20160729 22:15:16< iceiceice> or like macros of some kind
20160729 22:15:23< iceiceice> that would tell openmp "it is safe to parallelize this loop"
20160729 22:15:34< iceiceice> and we were doing that over the loop in the display that does each unit or something
20160729 22:15:35< vultraz> all I see is #pragma stuff
20160729 22:15:46< loonycyborg> openmp is enabled for release windows builds
20160729 22:15:47< iceiceice> i vaguely understood it at one point i think
20160729 22:15:50< iceiceice> i see
20160729 22:16:02< vultraz> there's some code in display::invalidate_animations()
20160729 22:16:31< loonycyborg> afaik boucman used it to speed up some tight loops
20160729 22:18:01-!- mjs-de [~mjs-de@x4e3157fd.dyn.telefonica.de] has quit [Remote host closed the connection]
20160729 22:18:04< iceiceice> i dont actually know how it works like
20160729 22:18:12< iceiceice> if it makes the code implicitly spawn some threads
20160729 22:18:24< shadowm> loonycyborg: Hopefully no-one will later report bugs against the original 1.13.5 tag.
20160729 22:18:28< iceiceice> or if the parallelization happens at a lower level, like telling the processor it can pipeline some things more efficiently
20160729 22:18:35< vultraz> 	//this loop must not be parallelized. refresh is not thread-safe,
20160729 22:18:36< vultraz> 	//for one, unit filters are not thread safe. this is because,
20160729 22:18:38< vultraz> 	//adding new "scoped" wml variables is not thread safe. lua itself
20160729 22:18:39< vultraz> 	//is not thread safe. when this loop was parallelized, assertion
20160729 22:18:41< vultraz> 	//failures were reported in windows openmp builds.
20160729 22:18:42 * vultraz rolls eyes
20160729 22:18:45< vultraz> is anything thread-safe?
20160729 22:18:52< iceiceice> no, nothing is thread-safe
20160729 22:19:05< iceiceice> i probably wrote that comment
20160729 22:19:19< shadowm> loonycyborg: How about the next time you just use a new version number instead of recreating a tag? Thanks.
20160729 22:19:19< celmin> Given that it was not announced and only existed for like twelve hours or less, I think it's probably unlikely.
20160729 22:19:20< loonycyborg> iceiceice: It spawns more threads
20160729 22:20:10< shadowm> celmin: The Debian packagers had already been pinged by vultraz.
20160729 22:20:27< shadowm> Also, it's still not good form. This isn't a thing that's up for discussion.
20160729 22:20:50< celmin> …true, on the Debian point.
20160729 22:21:02< vultraz> iceiceice: i thought one of the caveats of using boost::intrusive_ptr for units was it isn't thread_safe... so why would there be code that's supposed to parallelize things, but then have it be told not to do so because it's not safe to do so...
20160729 22:21:05< zookeeper> from what little experience i have with openmp, it seems like a very nice thing in some limited circumstances. please don't remove something just because you don't understand it.
20160729 22:21:21< vultraz> celmin, shadowm: apparently someone other than Rhonda deals with the debian stuff now.
20160729 22:21:27< loonycyborg> shadowm: How can anyone report a bug against a tag that no longer exists?
20160729 22:21:33< shadowm> vultraz: That's why I said plural.
20160729 22:21:41< vultraz> ah
20160729 22:22:08< celmin> I think Rhonda handles a different distribution too? Also, she pinged the actual debian maintainer when pointing that out.
20160729 22:22:24< shadowm> They are both the team that does Wesnoth for Ubuntu and Debian.
20160729 22:22:29< iceiceice> vultraz, idk what to tell you, you can read about thread safety if you want
20160729 22:22:30-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 258 seconds]
20160729 22:22:35< shadowm> Why are we going on a tangent anyway?
20160729 22:22:53< iceiceice> actually i have no idea why the stuff that boucman parallelized is thread-safe
20160729 22:23:00< iceiceice> but i didn't study it
20160729 22:23:02< vultraz> iceiceice: if we're gonna parallelize things why not just fully commit to using threads?
20160729 22:23:09< iceiceice> maybe the graphics pipeline is thread safe in some way
20160729 22:23:11< vultraz> or better yet, hw acceleration
20160729 22:23:14< iceiceice> i mean if the units are all at different hexes
20160729 22:23:19< celmin> I doubt the graphics pipline is thread-safe...
20160729 22:23:23< celmin> ^pipeline
20160729 22:23:25< iceiceice> vultraz, threadsafety does not come for free
20160729 22:23:45< iceiceice> celmin, yeah i have no explanation for why it would be okay to invalidate units in parallel
20160729 22:23:49< loonycyborg> vultraz: there's no reason openmp can't be used with manual threading
20160729 22:23:50< iceiceice> unless they are all touching different pixels
20160729 22:23:53< shadowm> loonycyborg: The bottomline is I'm not up for discussing semantics on a basic issue that everyone has agreed on for about as long as Git has existed.
20160729 22:24:17< vultraz> shadowm, loonycyborg: for the record, I did advise you use 1.13.5a as a tag
20160729 22:24:49< vultraz> no harm done in this case, I dont think
20160729 22:25:04< shadowm> My hope is that this won't happen again.
20160729 22:25:21< iceiceice> shadowm, what, a botched tag? or a moved tag
20160729 22:25:29< vultraz> moved
20160729 22:25:31< celmin> Both, really.
20160729 22:26:18< iceiceice> vultraz, openmp is pretty easy to use, its just a few annotations on these loops
20160729 22:26:20< iceiceice> and it just happens
20160729 22:26:25< iceiceice> fully committing to threads would be like...
20160729 22:26:32< iceiceice> idk we would make a bunch of mutexes everywhere?
20160729 22:26:44< shadowm> Right now baldras' repo clones have the old tag.
20160729 22:27:05< iceiceice> all that would get removed if we went to opengl
20160729 22:27:07< iceiceice> so why bother
20160729 22:27:13< shadowm> I guess I'll have to log into the host and fix that somehow.
20160729 22:27:47< vultraz> iceiceice: which is why i said hw acceleration is the superior solution to speeding up graphics stuff
20160729 22:27:59< iceiceice> yeah but thats a long way away
20160729 22:28:04< vultraz> yeah
20160729 22:28:08< iceiceice> and getting there is not furthered by deleting openmp stuff
20160729 22:28:15< vultraz> yeah, i agree
20160729 22:28:28 * vultraz wishes we could throw many moniez at Aginor
20160729 22:29:02< shadowm> loonycyborg: http://pastebin.com/raw/3Yx4XKir Any idea what the best way to correct this is?
20160729 22:30:09< loonycyborg> shadowm: hmm maybe delete that tag there too
20160729 22:30:22< shadowm> So, just delete and pull --tags?
20160729 22:30:34< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming 46bb3c38dbe3 / src/ (3 files in 3 dirs): Replace boost map_list_of with C++11 initializers https://github.com/wesnoth/wesnoth/commit/46bb3c38dbe3a88c9dc5a9c00f4cea7f7c2db7f5
20160729 22:30:36< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming 30e71ef572da / src/ (7 files in 5 dirs): Remove use of boost::unordered_map https://github.com/wesnoth/wesnoth/commit/30e71ef572da6532cdc67e04501967d8f12af443
20160729 22:30:38< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming 0649c75461fe / src/ (4 files in 3 dirs): Remove uses of boost::array https://github.com/wesnoth/wesnoth/commit/0649c75461fedb22b0d00d1c50d889cdc13c3584
20160729 22:30:40< irker680> wesnoth: Celtic Minstrel wesnoth:boost_trimming 2a88d0dd2c1c / src/ (map/location.cpp units/unit.cpp variable_info_detail.hpp): Remove a few other miscellanous Boost uses https://github.com/wesnoth/wesnoth/commit/2a88d0dd2c1cf8cae25002180419cf26576f3e4a
20160729 22:30:50< loonycyborg> shadowm: yes I think
20160729 22:30:53< loonycyborg> https://confluence.atlassian.com/bitbucket/how-do-i-remove-or-delete-a-tag-from-a-git-repo-282175551.html
20160729 22:30:54< celmin> Yeah, that's what I did.
20160729 22:30:58< loonycyborg> I followed this tip
20160729 22:31:01< celmin> git tag -d 1.13.5
20160729 22:31:05-!- enchi [~aeonchild@defocus/yummy/enchilado] has joined #wesnoth-dev
20160729 22:31:32< shadowm> Yeah, that fixes it. Good that I have the access required to do this in the first place.
20160729 22:31:51< shadowm> If this were two years ago I'd have to bother someone else and possibly wait days.
20160729 22:33:32< loonycyborg> I totally didn't expect that git can't keep track tags in sync :/
20160729 22:33:37< vultraz> celmin: sweet
20160729 22:33:50< vultraz> now we just need to solve travis..
20160729 22:34:13< vultraz> celmin: I suspect it might be one of those c++11 problems in 4.7 iceiceice spoke of
20160729 22:36:01< celmin> src/game_events/conditional_wml.cpp: In function ‘bool game_events::{anonymous}::internal_conditional_passed(const vconfig&)’:
20160729 22:36:02< celmin> src/game_events/conditional_wml.cpp:173:114: error: could not convert ‘{"true", "false", "have_unit", "have_location", "variable", "then", "else", "elseif", "not", "and", "or", "do"}’ from ‘<brace-enclosed initializer list>’ to ‘const boost::container::flat_set<std::basic_string<char> >’
20160729 22:36:29< vultraz> eh?
20160729 22:36:56< celmin> I don't think the travis failure is on the whole due to GC 4.7 issues, but there's at least one there ^
20160729 22:37:04< celmin> ^GCC
20160729 22:37:07< vultraz> blah
20160729 22:37:12< vultraz> didn't we agree to bump to 4.8?
20160729 22:37:27< celmin> I guess Boost's flat_set doesn't have an initializer_list constructor?
20160729 22:37:36< vultraz> it builds for me, js
20160729 22:37:53< shadowm> What has Javascript to do with this?
20160729 22:37:57< celmin> Then it's probably a matter of different Boost versions.
20160729 22:38:03< vultraz> what does travis use?
20160729 22:38:33< celmin> No idea.
20160729 22:38:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160729 22:39:06< iceiceice> why dont you try building with gcc 4.8 and 4.7 and see if it makes a difference?
20160729 22:39:24< bumbadadabum> what would I classify the trait generator change as in the changelog
20160729 22:39:40< celmin> I don't recall agreeing to bump to 4.7, but I also don't recall my reasonings for 4.7...
20160729 22:39:42< vultraz> iceiceice: can't we just bump travis and see if it passes?
20160729 22:39:49< iceiceice> you could
20160729 22:39:56< vultraz> bumbadadabum: what do you mean?
20160729 22:40:01< celmin> I think bumbadadabum asked an important question but I have no idea what the answer should be.
20160729 22:40:11< bumbadadabum> well, there are categories in the changelog
20160729 22:40:17< vultraz> bumbadadabum: oh. WML.
20160729 22:40:25< celmin> It's not really, though,
20160729 22:40:31< celmin> The help_text part fits under WML.
20160729 22:40:33< bumbadadabum> yeah
20160729 22:40:44< celmin> But the other part does not, and it doesn't quite feel like it fits UI either.
20160729 22:40:47< vultraz> this isn't an exact science
20160729 22:40:51< vultraz> just go WML
20160729 22:40:54< celmin> Okay then, go with UI.
20160729 22:41:00< vultraz> blah
20160729 22:41:01< bumbadadabum> I'll do both
20160729 22:41:04< vultraz> ok
20160729 22:41:05< celmin> Yeah, both.
20160729 22:41:14< celmin> Because it's mixed.
20160729 22:41:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 22:41:35< vultraz> iceiceice: how does one update travis to use 4.8?
20160729 22:42:04< celmin> Updates to travis involve editing .travis.yml. I suggest doing it on a branch if you're experimenting with stuff.
20160729 22:42:20< celmin> To update to 4.8 you might be able to just revert the commit that forces 4.7.
20160729 22:42:39< vultraz> celmin: we are on a branch
20160729 22:42:50< celmin> Oh right, doing it there.
20160729 22:43:02< celmin> BTW, Travis already has a 4.8 build
20160729 22:44:02< celmin> It's actually quite annoying, because it uses red for things other than errors.
20160729 22:44:22< vultraz> ok, I think these are the lines..
20160729 22:44:24< vultraz>           sudo apt-get install -qq g++-4.7;
20160729 22:44:26< vultraz>           export CXX=g++-4.7;
20160729 22:44:45< celmin> For the record, the GCC 4.8 build fails with the same error.
20160729 22:44:55< vultraz> hmmmm
20160729 22:45:12< celmin> In fact, so does the optimized clang build… o.o
20160729 22:45:13< vultraz> really would like to know what version of boost it uses
20160729 22:45:42< celmin> What happened to the translations build?
20160729 22:46:00< irker680> wesnoth: Bär Halberkamp wesnoth:master 4e71bbe44815 / / (5 files in 4 dirs): Generate trait help instead of hardcoding https://github.com/wesnoth/wesnoth/commit/4e71bbe44815f31533e438a93ef3350f6e1a5921
20160729 22:46:03< irker680> wesnoth: Bär Halberkamp wesnoth:master 7b61ce2400fa / / (5 files in 4 dirs): Merge pull request #715 from bumbadadabum/master https://github.com/wesnoth/wesnoth/commit/7b61ce2400fa23657a5f60a3a6aae7fa7c7aa421
20160729 22:46:29< bumbadadabum> vultraz: I'll do that gna bug you linked late
20160729 22:46:33< bumbadadabum> *later
20160729 22:46:35< vultraz> k
20160729 22:46:46< bumbadadabum> should only take a minute depending on how easy it is to find the code for it
20160729 22:46:47< celmin> vultraz: It works for me by the way, on Boost 1.57 I think.
20160729 22:47:28< celmin> bumbadadabum: It's either in src/units/ somewhere, or in src/scripting/game_lua_kernel.cpp
20160729 22:47:49< vultraz> according to INSTALL, we support versions of certain boost libraries going back to 1.36 O_O
20160729 22:47:58< celmin> INSTALL probably needs to be updated.
20160729 22:48:03< vultraz> likely
20160729 22:48:31< celmin> One of the Travis builds on clang does not fail.
20160729 22:49:12< vultraz> that one rarely fails
20160729 22:49:22< celmin> Huh? Why would that be?
20160729 22:49:31< vultraz> dunno
20160729 22:49:42< vultraz> it just almost never fails
20160729 22:50:22< celmin> Weird.
20160729 22:50:56< vultraz> I think that second build still uses 4.7 somehow..
20160729 22:51:13< celmin> The second build uses 4.8
20160729 22:51:16< vultraz> it says gcc 4.8 but then later it says 
20160729 22:51:18< vultraz> $ $CXX --version
20160729 22:51:19< vultraz> g++-4.7 (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
20160729 22:51:36< celmin> Oh, I was wrong, okay. Still, two of the clang builds are failing with the same error.
20160729 22:51:49< celmin> So it's not a GCC 4.7 problem specifically.
20160729 22:52:50< vultraz> i really don't understand this
20160729 22:53:01< celmin> vultraz, gfgtdf, any problems with PR 710?
20160729 22:53:25< vultraz> not from me
20160729 22:53:27< celmin> Although I guess we should merge boost first.
20160729 22:53:31< celmin> boost_trimming I mean.
20160729 22:53:56< vultraz> probably
20160729 22:54:11< vultraz> since it touches boost stuff
20160729 22:54:12< celmin> Because the PR duplicates a few of those changes, I think.
20160729 22:54:13< celmin> Yeah,
20160729 22:54:44< irker680> wesnoth: Gregory A Lundberg wesnoth:master 9623b746a999 / src/units/animation.cpp: Fix compiler warnings https://github.com/wesnoth/wesnoth/commit/9623b746a99972feed484510e5bcdd489fb8155b
20160729 22:54:46< irker680> wesnoth: Gregory A Lundberg wesnoth:master 001917bb32e5 / src/units/animation.cpp: Use utils::join where possible https://github.com/wesnoth/wesnoth/commit/001917bb32e5fe1c8a25f789989ec35065a6b194
20160729 22:54:48< irker680> wesnoth: Celtic Minstrel wesnoth:master b895abd33183 / src/units/animation.cpp: Merge pull request #705 from GregoryLundberg/GL_fix_warnings_in_units_animation_ https://github.com/wesnoth/wesnoth/commit/b895abd331838a37742bd0671e25b72f92d85394
20160729 22:54:50< irker680> wesnoth: Celtic Minstrel wesnoth:master 997464d630e2 / src/units/animation.cpp: Build joined string once instead of twice https://github.com/wesnoth/wesnoth/commit/997464d630e259dd586c9ca54f4839819a4c2877
20160729 22:54:52< irker680> wesnoth: Celtic Minstrel wesnoth:master 37fe451bde81 / src/units/animation.cpp: Remove obsolete commented code https://github.com/wesnoth/wesnoth/commit/37fe451bde81d10ba86dbbfda8b470067e2b0aea
20160729 22:54:54< irker680> wesnoth: Celtic Minstrel wesnoth:master 0b57922488b1 / src/units/animation.cpp: Output to requested stream instead of cout https://github.com/wesnoth/wesnoth/commit/0b57922488b139052a6c7a5034813a386acb2c0b
20160729 22:54:56< irker680> wesnoth: Celtic Minstrel wesnoth:master 63081cac467d / src/units/ (animation.cpp animation.hpp animation_component.hpp udisplay.cpp): Simplify enum output with std::transform https://github.com/wesnoth/wesnoth/commit/63081cac467df9fb4f6f25403f4b65cba7b932e1
20160729 22:54:58< irker680> wesnoth: Celtic Minstrel wesnoth:master d58697e7772d / src/ (scripting/plugins/context.hpp theme.hpp units/animation.hpp units/frame.hpp): Eliminate C-style enum/struct declarations https://github.com/wesnoth/wesnoth/commit/d58697e7772d1707bf2bf43da54dcee4c66b1eff
20160729 22:55:00< irker680> wesnoth: Celtic Minstrel wesnoth:master 7ca8897ff58d / src/ (7 files in 3 dirs): Merge pull request #707 from CelticMinstrel/uanim_output_cleanup https://github.com/wesnoth/wesnoth/commit/7ca8897ff58d4c2a61358fce6d30d06b14de33ea
20160729 22:56:26< celmin> Okay, so, the PRs to deal with are 717, 716, 710, 702, 698, 684, 674, 671...
20160729 22:56:43< vultraz> many many prs :P
20160729 22:56:48< celmin> spirit_po needs exception handling and possible scons/CMake updates, so can't merge that quite yet.
20160729 22:57:02< celmin> I think we're letting Aginor handle Monte Carlo.
20160729 22:57:06< vultraz> let's deal with boost first
20160729 22:57:12< celmin> vultraz: I didn't even include all of Tad's campaign PRs. :P
20160729 22:57:45< celmin> The mute PR was supposed to be changed to pause instead...
20160729 22:57:56< celmin> (Or I suppose, offering both options? I dunno.)
20160729 22:58:20< celmin> 717 is still labelled WIP, so maybe not quite ready yet.
20160729 22:58:27< vultraz> I wonder if travis would pass if it were an std::set
20160729 22:58:41< celmin> It would. I wonder if there's a reason for it to be a flat_set.
20160729 22:58:49< gfgtdf> celmin: well i still don't see andvantages, on the other i say a more complacte c++ code is always a disavantage.
20160729 22:59:47-!- fabi [~fabi@176.5.22.173] has joined #wesnoth-dev
20160729 22:59:47< vultraz> celmin: flat_set has superior insert/remove performance for a small number of operations... but I think this is just for searching
20160729 23:00:01< vultraz> celmin: (ref http://blog.fellstat.com/?p=376 )
20160729 23:00:05< celmin> It's just for searching, yes.
20160729 23:00:09-!- fabi [~fabi@176.5.22.173] has quit [Changing host]
20160729 23:00:09-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20160729 23:00:15-!- travis-ci [~travis-ci@ec2-54-198-60-9.compute-1.amazonaws.com] has joined #wesnoth-dev
20160729 23:00:16< travis-ci> wesnoth/wesnoth#9997 (boost_trimming - 2a88d0d : Celtic Minstrel): The build is still failing.
20160729 23:00:16< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/148448193
20160729 23:00:16-!- travis-ci [~travis-ci@ec2-54-198-60-9.compute-1.amazonaws.com] has left #wesnoth-dev []
20160729 23:00:39< vultraz> celmin: so, any objections to making it a set?
20160729 23:00:51< celmin> Let me at least read your reference before deciding.
20160729 23:01:15-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has quit [Remote host closed the connection]
20160729 23:03:14< celmin> The reference says that flat_set is faster for search.
20160729 23:04:50< celmin> But no indication on how much.
20160729 23:05:34< vultraz> I assume an unordered_set wouldn't be better
20160729 23:06:08< celmin> unordered_set would be better than set, but not sure how it compares to flat_set.
20160729 23:08:13< celmin> Apparently I might be wrong on that.
20160729 23:08:22< vultraz> I think flat_set is probably best here
20160729 23:08:29< vultraz> we might have to revert the initilizer list change
20160729 23:08:38< celmin> Only for flat sets though.
20160729 23:09:06< iceiceice> flat_set is kind of janky though
20160729 23:09:10< iceiceice> idk i mean it sounds like a good idea
20160729 23:09:18< iceiceice> i asked htis question once and no one gave me a reasonable answer:
20160729 23:09:19< iceiceice> http://stackoverflow.com/questions/38166063/why-is-boostcontainerflat-set-not-nothrow-move-constructible
20160729 23:10:43< vultraz> iceiceice: so in your opinion, for a static, const list of strings that's just used for comparison lookup, would you use a flat_set, set, unordered_set, or vector?
20160729 23:11:01< iceiceice> if the list does not have thousands of elements it literally doesnt matter
20160729 23:11:28< vultraz> it does not
20160729 23:11:31< vultraz> at most, 30
20160729 23:11:38< vultraz> or maybe more
20160729 23:11:56< vultraz> but certainly not even 3 digits
20160729 23:12:26< celmin> Okay, let's just switch to set then.
20160729 23:13:28< iceiceice> vultraz, if you want maximum performance,
20160729 23:13:45< iceiceice> you could use a typelist containing types that have static constexpr const char * member functions that provide the strings
20160729 23:13:50< iceiceice> and iterate over it at compile time
20160729 23:13:52< iceiceice> :)
20160729 23:14:24< celmin> Except without the constexpr, because MSVC 2013.
20160729 23:14:47< celmin> But I think that's probably not worth it?
20160729 23:15:07< iceiceice> yeah it would be needlessly complicated
20160729 23:15:26< iceiceice> you could just use an array i guess
20160729 23:15:42< iceiceice> then it can be initialized more easily than any of the dynamic data structures
20160729 23:15:53< iceiceice> or use `std::array`
20160729 23:16:28< celmin> An array means linear search though, whereas a set is binary search.
20160729 23:16:50< celmin> The sole purpose of this set is to ask the question "is this string in the set".
20160729 23:16:53< iceiceice> hehe
20160729 23:17:08< iceiceice> sounds like you know what the answer is then
20160729 23:17:20< celmin> Admittedly there's a binary search for sorted strings, but that's still higher-maintenance.
20160729 23:17:30< celmin> ^sorted containers
20160729 23:17:50< celmin> (I mean, there's std::binary_search if I recall correctly, which assumes the collection is sorted.)
20160729 23:18:28< iceiceice> i've been told that for just like, random short strings, std::unordered_map is faster than std::map
20160729 23:18:35< iceiceice> and i would assume std::unordered_set is also
20160729 23:18:39< iceiceice> but i never measured this or anything
20160729 23:18:41< celmin> Well, these aren't random, but maybe.
20160729 23:18:55< iceiceice> i mean like for generic human readable strings
20160729 23:20:05< fabi> hello
20160729 23:20:10< celmin> Hi
20160729 23:20:24< bumbadadabum> woah fabi
20160729 23:20:32 * vultraz p_p
20160729 23:20:35< bumbadadabum> long time no see as well
20160729 23:20:46 * celmin doesn't understand vultraz's emote
20160729 23:21:06< vultraz> surprised bulging eyes
20160729 23:23:14-!- gfgtdf [~chatzilla@x4e36ada5.dyn.telefonica.de] has joined #wesnoth-dev
20160729 23:26:39< fabi> hi bumbadadabum
20160729 23:26:51< gfgtdf> vultraz: flat_set is basically a sorted vector, so that you can find thing with binary search. finding and iterating over elements perfoamcne faster than on a std::set simply mostly becaue with a std::set the elements might be quiet scattered in memory.
20160729 23:28:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160729 23:28:54< vultraz> I see
20160729 23:29:50< irker680> wesnoth: Charles Dang wesnoth:boost_trimming e8b4b447d404 / src/ (game_events/conditional_wml.cpp play_controller.cpp team.cpp team.hpp): Convert uses of boost::flat_set to std::set https://github.com/wesnoth/wesnoth/commit/e8b4b447d404f004242d5794cc10eba10fd26f4a
20160729 23:29:56< vultraz> let's see what travis says now
20160729 23:30:54< bumbadadabum> can you literally just take any letter, repeat it twice, add an underscore, and call it an emoticon?
20160729 23:31:22< vultraz> depends
20160729 23:31:41< gfgtdf> vultraz: why do you want to make it std::set ?
20160729 23:31:59< vultraz> gfgtdf: travis is complaining 
20160729 23:32:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160729 23:32:48< celmin> gfgtdf: Some version of flat_set seems not to support initializers.
20160729 23:33:03< celmin> Which is odd, because it works for me and for vultraz.
20160729 23:35:43< gfgtdf> celmin: whihc boost version do you use ?
20160729 23:35:58< celmin> gfgtdf: And it's a const set with very few elements, so the performance boost probably from flat_set probably isn't that noticeable.
20160729 23:36:04< celmin> I think I use 1.57.
20160729 23:36:37< celmin> Maybe it was 1.58.
20160729 23:36:41< vultraz> I use 1.158
20160729 23:36:44< vultraz> 1.58*
20160729 23:37:05< gfgtdf> celmin: this seems to be commit that adds support for initilzer lists to flat_set: https://github.com/boostorg/container/commit/cbe191b5e32fd0cc5768105b05af7173e16da8b2
20160729 23:37:15< gfgtdf> celmin: do i'D think its supported sicne 1.57
20160729 23:37:32< celmin> So Travis is using a version of Boost older than 1.57?
20160729 23:37:52< vultraz> what version of boost does debian stable ship?
20160729 23:37:53< gfgtdf> celmin: seems likeley to me speciall sicne it also uses gcc 4.7
20160729 23:38:15< celmin> gfgtdf: It's failing on clang too.
20160729 23:39:25< gfgtdf> celmin: y that was more like 'if is uses a so old gcc vrsion then i'd not be suproised it it also uses an old boost version
20160729 23:40:11< celmin> vultraz: Appears to be 1.55.
20160729 23:40:19< vultraz> hm
20160729 23:40:25< vultraz> I guess we need to support that :/
20160729 23:40:36< celmin> Yeah.
20160729 23:40:44< celmin> That's probably what Travis is building with too, right?
20160729 23:41:08< gfgtdf> celmin: i read './libboost-regex1.54-dev_1.54.0-4ubuntu3.1_amd64.deb ...' in the travis output so i'D guess 1.54
20160729 23:41:27< celmin> Hmm.
20160729 23:41:32< celmin> Oh, Ubuntu.
20160729 23:41:40< vultraz> i dunno, I think travis gets stuff from ubuntu?
20160729 23:42:20-!- Duthlet [~Duthlet@dslb-178-005-055-087.178.005.pools.vodafone-ip.de] has quit [Quit: leaving]
20160729 23:42:21< celmin> Which Ubuntu?
20160729 23:42:24< gfgtdf> vultraz: maybe you can use some #if liek in #if boost_version >= 1.57  using set_type = boost::flat_set #else using set_type = std::set #endif ?
20160729 23:42:36< iceiceice> vultraz, you can just download boost from source forge in the travis script
20160729 23:42:36< celmin> Ubuntu 14 maybe.
20160729 23:42:43< celmin> Or 15?
20160729 23:42:45< iceiceice> and put it in your cache directory
20160729 23:42:50< celmin> Not 16 since that has Boost 1.58.
20160729 23:43:01< iceiceice> celmin, it uses either 12.04 or 14.04
20160729 23:43:05< iceiceice> depending on how you configure it
20160729 23:43:07< celmin> Even worse.
20160729 23:43:10< celmin> Potentially.
20160729 23:43:45< iceiceice> i've been basically copying this guy in my projects:
20160729 23:43:46< iceiceice> https://github.com/boostorg/hana/blob/master/.travis.yml
20160729 23:44:06< celmin> Trusty indeed has 1.54.
20160729 23:45:34< gfgtdf> celmin: another option might be to use docker if you wan to update travis build to something newer, this woudl also make a c++14 test buidl work.
20160729 23:45:35< celmin> I don't remember if we said we're going to continue supporting Trusty.
20160729 23:45:51< celmin> Docker?
20160729 23:46:13< gfgtdf> celmin: well i dotn thik we shodul drop support just becasue we thignk initilizer lists are cleaner that boost::assign
20160729 23:46:18< gfgtdf> than*
20160729 23:46:34< celmin> Trusty doesn't even have Wesnoth 1.12.
20160729 23:46:48< celmin> It's still on 1.10, like debian oldstable.
20160729 23:47:09< celmin> gfgtdf: You're right.
20160729 23:47:24< celmin> Lemme look up my email.
20160729 23:47:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160729 23:47:40< gfgtdf> celmin: wel i'm not really a linux expert so i dont have any strong opinion on which versions we should support
20160729 23:50:20-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 258 seconds]
20160729 23:51:13< celmin> Well, the compatibility table shows that we can still support trusty.
20160729 23:54:17< iceiceice> i would be really suprised if there are any users who actually use trusty still on their game machines
20160729 23:54:32-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160729 23:54:38< celmin> Me too, given it doesn't even have Wesnoth 1.12.
20160729 23:54:54< celmin> So while we can support trusty, I don't necessarily think we should.
20160729 23:54:58< vultraz> is the deletion of copy constructors always class(const class&) = delete?
20160729 23:55:25< celmin> Yes. It would work without the const or without the &, I suppose, but generally you don't want that.
20160729 23:55:54< celmin> Oh wait, I guess it can't work without the & probably.
20160729 23:56:08< celmin> Because that would mean that it needs to call the copy constructor in order to call the copy constructor.
20160729 23:56:28< gfgtdf> vultraz: you mostlikeley want to deelte the assigment operator too
20160729 23:56:33< gfgtdf> delete
20160729 23:56:34< celmin> Yes.
20160729 23:56:46< celmin> Are you removing boost::noncopyable after all?
20160729 23:57:00< vultraz> well i have a commit locally doing that
20160729 23:57:06< celmin> I personally don't really care that much, but it does have some minor advantage.
20160729 23:57:10< vultraz> dunno if it's realllyy, worth it
20160729 23:58:47< vultraz> how does one delete an assignment operator?
--- Log closed Sat Jul 30 00:00:59 2016