--- Log opened Sun Jul 17 00:00:14 2016
20160717 00:02:05< mattsc> celticminstrel: I’m off again, I’ll check out the remaining changes within the next day or two.
20160717 00:02:11< celticminstrel> Okay.
20160717 00:04:08-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160717 00:06:32-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has joined #wesnoth-dev
20160717 00:43:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160717 00:45:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 00:46:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160717 00:46:10-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 00:54:12-!- stikonas_ is now known as stikonas
20160717 00:54:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160717 00:54:44-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 01:15:06-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160717 01:15:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 01:17:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160717 01:25:51-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 240 seconds]
20160717 01:45:03-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 240 seconds]
20160717 01:47:41-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160717 01:55:26-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160717 01:55:45-!- gfgtdf_ [~chatzilla@x4e3630e0.dyn.telefonica.de] has joined #wesnoth-dev
20160717 01:58:33-!- gfgtdf [~chatzilla@x4e32b78c.dyn.telefonica.de] has quit [Ping timeout: 276 seconds]
20160717 01:58:40-!- gfgtdf_ is now known as gfgtdf
20160717 02:29:57-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160717 02:30:50-!- gfgtdf [~chatzilla@x4e3630e0.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160717 02:37:26-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160717 03:01:22-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160717 03:15:40-!- irker861 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160717 03:15:40< irker861> wesnoth: Andreas Löf wesnoth:Vultraz-event_handling_fixes 75632003efef / src/ (events.cpp events.hpp preferences.cpp): Add a destructor to the context class. https://github.com/wesnoth/wesnoth/commit/75632003efef78b1d2fe9f47c6a7e4dabc47de22
20160717 03:15:46< Aginor> vultraz: give that commit a go when you have the time
20160717 03:16:56< vultraz> Aginor: is the removal of splice necessary for gcc 4.x?
20160717 03:17:22< Aginor> vultraz: travis will tell us
20160717 03:18:11< vultraz> building your change
20160717 03:18:36< vultraz> Aginor: travis is using 4.7, though, and you said we could update to 4.8
20160717 03:19:03< Aginor> vultraz: I said "it depends"
20160717 03:19:16< Aginor> what platforms do we target?
20160717 03:19:20< vultraz> It was using 4.8 before, you know
20160717 03:19:24< vultraz> Then you reduced it
20160717 03:19:42< Aginor> no, I didn't, I haven't touched those things
20160717 03:19:46< vultraz> Well, someone did
20160717 03:19:49< Aginor> I have however argued about it
20160717 03:20:09< Aginor> someone probably implemented the decision to stick with 4.7 as our minimum supported version
20160717 03:20:23< vultraz> Look, if we lose debian oldstable, how much of a loss is it. Why do we need to support an old stable version.
20160717 03:22:29< Aginor> vultraz: according to http://popcon.debian.org/ , 1/3 of the debian users
20160717 03:23:22< vultraz> I can't understand a thing on that page
20160717 03:23:40< Aginor> just looking at those numbers, but the survey sample might be horribly skewed so I don't think we can draw too many reliable conclusions from it
20160717 03:24:12< vultraz> Don't forget supported compilers is different from supported OSes
20160717 03:24:48< Aginor> vultraz: I'm not, but they're also tied to glibc versions
20160717 03:25:13< vultraz> Does that mean that an oldstable user cannot update to 4.8?
20160717 03:25:21< celticminstrel> I don't even remember if that decision included support for debian oldstable.
20160717 03:25:31< Aginor> neither
20160717 03:25:41< celticminstrel> vultraz: It means they need to jump through more hoops to update.
20160717 03:25:44< Aginor> do we have anything about this in the mailing list archives?
20160717 03:25:51< celticminstrel> 4.8 is not in their package repos.
20160717 03:25:56< celticminstrel> Aginor: I think it should be there,
20160717 03:26:02< vultraz> Yes, I think so
20160717 03:26:47< vultraz> Aginor: you yourself mentioned we'd lose debian oldstable
20160717 03:26:54< vultraz> Aginor: and lipkab supported it
20160717 03:27:03< vultraz> "Both Debian oldstable and CentOS are so notoriously behind in terms of software updates that anybody using them as a desktop OS probably very well understands what that means for them regarding package availability."
20160717 03:27:05< Aginor> vultraz: link?
20160717 03:27:52 * Aginor gives up on the official archives
20160717 03:28:08< vultraz> https://mail.gna.org/public/wesnoth-dev/2016-03/msg00002.html
20160717 03:28:37< vultraz> the gna mailing list archives have such a shitty UI
20160717 03:28:41< Aginor> https://mail.gna.org/public/wesnoth-dev/2016-03/msg00004.html
20160717 03:29:13< Aginor> https://mail.gna.org/public/wesnoth-dev/2016-03/msg00001.html
20160717 03:29:40< vultraz> so it was celticminstrel who decided on 4.7
20160717 03:29:52< celticminstrel> Yes, I could have told you that.
20160717 03:30:07< Aginor> and nobody objected since we found it acceptable
20160717 03:30:21 * Aginor shrugs
20160717 03:30:33< Aginor> I'm still happy with 4.7, I think it's a good compromise
20160717 03:31:03< vultraz> Aginor: crash seems to be fixed
20160717 03:31:14< vultraz> I launched and quit the game 12 times and it does not crash
20160717 03:31:28< Aginor> good
20160717 03:31:52< Aginor> this still backs my theory of different compilers doing things in different orders in _exit()
20160717 03:32:12< vultraz> so, should we merge the branch?
20160717 03:32:54< Aginor> vultraz: can you please test a bit more as the bug has been coming and going for you?
20160717 03:34:25< vultraz> failed to crash 20 times in a row
20160717 03:34:38< celticminstrel> Wait, did that remove the splice though?
20160717 03:34:57< vultraz> yes, Aginor said it breaks on older gcc compilers
20160717 03:35:01< vultraz> for some reason
20160717 03:35:06< celticminstrel> That's not a reason to remove it.
20160717 03:35:23< vultraz> I do not agree with its removal
20160717 03:35:24< celticminstrel> (Unless you substituted something else with the same effect.)
20160717 03:35:37< vultraz> He did
20160717 03:35:41< celticminstrel> Ah, I see he did.
20160717 03:36:06< Aginor> celticminstrel: they are both supposed to be O(1)
20160717 03:36:09-!- travis-ci [~travis-ci@ec2-54-82-136-49.compute-1.amazonaws.com] has joined #wesnoth-dev
20160717 03:36:10< travis-ci> wesnoth/wesnoth#9822 (Vultraz-event_handling_fixes - 7563200 : Andreas Löf): The build is still failing.
20160717 03:36:10< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/145300377
20160717 03:36:10-!- travis-ci [~travis-ci@ec2-54-82-136-49.compute-1.amazonaws.com] has left #wesnoth-dev []
20160717 03:36:27< Aginor> vultraz: no, we shouldn't merge it yet
20160717 03:36:33< celticminstrel> Uh, hang on, since when was foc a focus_handler*?
20160717 03:36:38< celticminstrel> Wasn't it an iterator?
20160717 03:36:53< celticminstrel> Splice's third parameter should be an iterator, right?
20160717 03:37:11< Aginor> celticminstrel: it should be yes
20160717 03:37:18< Aginor> https://travis-ci.org/wesnoth/wesnoth/jobs/145300378#L1813
20160717 03:37:22 * Aginor makes a face
20160717 03:37:46< Aginor> I should prepare a docker image to use to compile wesnoth with 4.7
20160717 03:38:07< vultraz> OH COME ON, TRAVIS
20160717 03:38:51< Aginor> also, googling std::list may not yield the results you had in mind
20160717 03:39:33< celticminstrel> It was an iterator in 61ccf2f...
20160717 03:39:42< vultraz> Aginor: I am aware :P
20160717 03:39:48< vultraz> celticminstrel: it is an iterator
20160717 03:39:57< Aginor> celticminstrel: the problem seems to be const_iterator vs iterator
20160717 03:41:14< celticminstrel> Oh, you're right. Sorry, I somehow confused it with foc_hand.
20160717 03:41:32< celticminstrel> Aginor: You don't think it would yield the correct result?
20160717 03:43:47< Aginor> celticminstrel: a const_iter?
20160717 03:44:07< Aginor> I think it does, I think the bigger issue is around whether it compiles or not :D
20160717 03:44:32< celticminstrel> A const_iterator is like const T*, right?
20160717 03:44:44< celticminstrel> Splice doesn't alter the data, so I think it should work?
20160717 03:46:01< Aginor> celticminstrel: this is what I was trying to fix there:
20160717 03:46:02< Aginor> https://travis-ci.org/wesnoth/wesnoth/jobs/144822541#L1812
20160717 03:48:07-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160717 03:48:57< celticminstrel> Well, it's pretty clear that it is caused by it being a const_iterator, from the error message.
20160717 03:49:08< Aginor> yeah
20160717 03:49:32< Aginor> so I'm thinking that maybe we should let it be .splice again, and move to just an iterator
20160717 03:49:49< celticminstrel> From the docs it appears that the const_iterator forms are in fact C++11.
20160717 03:50:08< celticminstrel> It probably won't hurt to make it a non-const iterator, I guess.
20160717 03:50:14< vultraz> and if 4.7 has problems with c++11, maybe that's the problem
20160717 03:50:23< celticminstrel> Did I specify a reason for making it const beyond mere const-correctness?
20160717 03:51:21< celticminstrel> Actually, C++11 removed the iterator versions in favour of const_iterator versions.
20160717 03:51:30< celticminstrel> I guess because iterator is convertible to const_iterator.+
20160717 03:58:37< Aginor> indeed
20160717 03:58:52< Aginor> whereas conversion in the other direction is not so nice
20160717 03:59:16< celticminstrel> Obviously.
20160717 03:59:19< Aginor> I'm ditching a bunch of constedness from that branch now to see if that makes travis happier
20160717 04:01:40< irker861> wesnoth: Andreas Löf wesnoth:Vultraz-event_handling_fixes 6964aa2ba7aa / src/ (events.cpp events.hpp): Change const_iterator to iterator in an attempt to appease travis. https://github.com/wesnoth/wesnoth/commit/6964aa2ba7aaee99823c9bdd7b3fc40ba8d9c5eb
20160717 04:13:25< iceiceice> one thing you should keep in mind also,
20160717 04:13:32< iceiceice> alot of those changes as they relate to C++11,
20160717 04:13:36< iceiceice> like,
20160717 04:13:44< iceiceice> the standard library does not become C++11 until gcc-5
20160717 04:13:55< iceiceice> gcc 4.7 has most of the features
20160717 04:14:03< iceiceice> in 4.9, the language features are no longre considered experimental
20160717 04:14:10< iceiceice> but the changes to stdlib dont happen until gcc 5
20160717 04:14:13< Aginor> iceiceice: that's a very good point
20160717 04:14:26< celticminstrel> None of them?
20160717 04:14:27< iceiceice> so on travis you will still have a gcc 4 series standard library
20160717 04:14:53< iceiceice> this was my main complaint in the issue i raised there recently
20160717 04:14:54< iceiceice> https://github.com/travis-ci/travis-ci/issues/6300
20160717 04:15:13< iceiceice> usually it doesn't really matter
20160717 04:15:24< iceiceice> but sometimes if you are expecting something to be declared "noexcept" it wont be
20160717 04:15:35< iceiceice> i guess these `const_iterator` things wont hav etaken effect yet
20160717 04:15:45< iceiceice> there was a big change to `std::string`
20160717 04:16:16< iceiceice> in gcc 4-series, std::string is implicitly reference counted and does some "copy-on-write" shenanigans
20160717 04:16:25< iceiceice> but this makes it much less thread-safe
20160717 04:16:35< iceiceice> so in c++11 they decided to ban that basically
20160717 04:17:07< iceiceice> you can get some wierd problems because of this stuff
20160717 04:19:39< vultraz> and I guess we can't support only gcc 5
20160717 04:20:25< iceiceice> i mean it usually doensn't matter
20160717 04:20:41< iceiceice> but sometimes you will get different behavior locally from on travis because of tihngs like this
20160717 04:21:14< iceiceice> brb
20160717 04:27:45< Aginor> ok, the last commit has appeased travis
20160717 04:28:03< celticminstrel> What about the splice?
20160717 04:28:57< Aginor> I didn't put it back
20160717 04:29:06< Aginor> it should work now though
20160717 04:29:49< Aginor> I'm more worried by the small differences in the implementation in the remove_handler call
20160717 04:33:40-!- travis-ci [~travis-ci@ec2-54-90-194-136.compute-1.amazonaws.com] has joined #wesnoth-dev
20160717 04:33:41< travis-ci> wesnoth/wesnoth#9824 (Vultraz-event_handling_fixes - 6964aa2 : Andreas Löf): The build is still failing.
20160717 04:33:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/145303925
20160717 04:33:41-!- travis-ci [~travis-ci@ec2-54-90-194-136.compute-1.amazonaws.com] has left #wesnoth-dev []
20160717 04:33:55< vultraz> well thats an improvement
20160717 04:34:28< Aginor> https://travis-ci.org/wesnoth/wesnoth/jobs/145303929
20160717 04:34:46< Aginor> question is, is that us or somehting else that's gone wrong
20160717 04:36:22< celticminstrel> Hm?
20160717 04:37:55-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160717 04:38:19< celticminstrel> Looks like a segfault in the MP test.
20160717 04:39:13< celticminstrel> I think it only happens sometimes? Maybe someone should see if they can reproduce it on their own computer...
20160717 04:39:33< celticminstrel> (But it's probably unrelated to that branch, at least.0
20160717 04:39:42< celticminstrel> (I would think?)
20160717 04:41:16< Aginor> I think we need to establish that ;)
20160717 04:41:17 * vultraz groans
20160717 04:41:59-!- Appleman1234 [~Appleman1@KD036012044130.au-net.ne.jp] has quit [Ping timeout: 244 seconds]
20160717 04:47:01< celticminstrel> I'm getting "error server: could not make fifo at '/var/run/wesnothd/socket' (No such file or directory)"
20160717 04:47:15< celticminstrel> Presumably from trying to start wesnothd.
20160717 04:49:50< celticminstrel> Hmm...
20160717 04:50:44-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160717 04:52:40< celticminstrel> The path /var/run exists but there is no wesnothd directory there...
20160717 04:54:40-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 252 seconds]
20160717 04:54:40-!- wedge010 is now known as wedge009
20160717 04:56:06< shadowm> That's a normal error and it's not supposed to be fatal. And wesnothd should not have the ability to write there unless you set it up beforehand or are running wesnothd as root.
20160717 04:56:24< celticminstrel> Hmm, okay then.
20160717 05:03:50< celticminstrel> "terminate called throwing an exception" - but I can't tell yet whether that was the server or client...
20160717 05:04:08< celticminstrel> My process list still seems to have all three...
20160717 05:04:13-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160717 05:04:14-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160717 05:04:43< celticminstrel> Ah, it was the server, as I expected.
20160717 05:05:16< celticminstrel> Incidentally, I wonder if the client can be made to terminate as well in the event of an error...
20160717 05:05:54-!- Appleman1234 [~Appleman1@KD036012050155.au-net.ne.jp] has joined #wesnoth-dev
20160717 05:06:17< shadowm> I did say wesnothd.
20160717 05:06:35< celticminstrel> The terminate was unrelated to the /var/run thing, sorry.
20160717 05:07:02< celticminstrel> At least, I'm assuming it was. I haven't debugged it yet, waiting for XCode to build.
20160717 05:07:13< shadowm> If the client ended up calling std::terminate it'd have pretty obvious consequences.
20160717 05:07:19< celticminstrel> Hm?
20160717 05:07:27< shadowm> "terminate called throwing an exception"
20160717 05:07:36< celticminstrel> What consequences do you mean?
20160717 05:07:56< celticminstrel> It's running nogui, so it's not like I can see what's going on...
20160717 05:08:14< celticminstrel> ...wait, what does the --mp-test flag actually do...
20160717 05:09:04< celticminstrel> Oh, specifies scenarios.
20160717 05:11:54< celticminstrel> I can say that the crash occurs after client connection.
20160717 05:12:12< celticminstrel> I dunno if it's the same as what's happening on Travis though.
20160717 05:14:40< celticminstrel> BTW, I'm trying this on master at the moment, not on the events branch.
20160717 05:16:26-!- Kwandulin [~Miranda@p200300760F2D81C6F001C073D2FE8ABF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160717 05:22:20-!- Kwandulin_2 [~Miranda@p200300760F2D81C6F001C073D2FE8ABF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160717 05:22:40< Aginor> celticminstrel: if it's crashing on master I'm less worried about it on the feature branch
20160717 05:22:53< Aginor> it should just be a release blocker then
20160717 05:22:59-!- Kwandulin [~Miranda@p200300760F2D81C6F001C073D2FE8ABF.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160717 05:23:18< celticminstrel> Not sure if it's the same crash though, given that it's an exception rather than a segfault.
20160717 05:23:24< Aginor> right
20160717 05:38:39< celticminstrel> Auto-attach worked, yay. Now I should be able to see where it crashed.
20160717 05:39:45< celticminstrel> Hmm, the Lua scripts it presumably relies on are not being found... (that's not the crash cause though, as that's client-side)
20160717 05:40:20< celticminstrel> Crash is at simple_wml.cpp, line 64, in istream::read.
20160717 05:43:22< Aginor> on master?
20160717 05:44:19< celticminstrel> Yeah. And if I set a breakpoint on exception throw, it's in boost/filter/iostreams/zlib.hpp, line 387. Dunno if that's helpful.
20160717 05:44:54< celticminstrel> Since line numbers probably differ depending on Boost versions, that's zlib_error::check within zlib_decompressor_impl<Alloc>::filter
20160717 05:45:29< celticminstrel> I'm not really sure what it means, but it sort of looks similar to the ios::sentry or whatever.
20160717 05:48:46< celticminstrel> Ooh, xinflate returned -3
20160717 05:49:15< celticminstrel> Still not quite sure what that means...
20160717 05:51:17< Aginor> that decompressing something went poorly?
20160717 05:51:24< Aginor> and maybe it set an error code? :D
20160717 05:51:33< celticminstrel> If it's the same as inflate's return codes, it's Z_DATA_ERROR.
20160717 05:52:05< celticminstrel> Which means it received input which is not valid compressed data.
20160717 05:52:20< celticminstrel> Or incorrect checksum or something.
20160717 05:52:45< celticminstrel> "inflate() returns ... Z_DATA_ERROR if the input data was corrupted (input stream not conforming to the zlib format or incorrect check value) ..."
20160717 05:52:52< celticminstrel> (from zlib docs)
20160717 05:53:17< celticminstrel> So the client sent bad data, I guess?
20160717 05:53:48< celticminstrel> I'm going to see if the inability to find the plugins is related.
20160717 05:55:57< celticminstrel> Hmm.
20160717 05:56:15< celticminstrel> The files are at the repo toplevel.
20160717 05:56:23< celticminstrel> And I'm running the test script from there.
20160717 05:56:29< celticminstrel> So it should be able to find them, right?
20160717 05:56:33< celticminstrel> Why can't it?
20160717 05:57:06< celticminstrel> Oh, wait, it said "could not open 'host.lua' for reading"... what exactly does that actually mean...
20160717 05:58:11< celticminstrel> It means the istream's failbit was set.
20160717 05:59:02-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160717 06:03:08< celticminstrel> ...which probably means the file doesn't exist, though could also mean lack of read access (but that shouldn't be the problem...)
20160717 06:03:39< celticminstrel> Well, I guess I'll see if I can figure it out tomorrw.
20160717 06:03:42< celticminstrel> ^tomorrow
20160717 06:03:53-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160717 06:07:08< Aginor> ah, excellent
20160717 06:07:21< Aginor> I've reproduced it here
20160717 06:09:15< Aginor> and it's related to our changes
20160717 06:16:00< vultraz> eh?
20160717 06:16:04< vultraz> we broke something?
20160717 06:16:25< Aginor> vultraz: yes
20160717 06:34:13< Aginor> trying to operate on an already destroyed handler...
20160717 06:34:24 * Aginor sighs
20160717 06:34:43-!- Kwandulin_2 [~Miranda@p200300760F2D81C6F001C073D2FE8ABF.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160717 06:35:21< Aginor> I might be able to solve this by changing how the global context is created
20160717 06:35:31< Aginor> and put it on the stack instead
20160717 07:00:56< Aginor> but it'll all be ugly :/
20160717 07:02:11-!- irker861 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160717 07:09:20-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160717 07:20:30-!- Shiki [~Shiki@141.39.226.227] has quit [Quit: Verlassend]
20160717 08:00:43-!- JyrkiVesterinen [~JyrkiVest@87-100-160-159.bb.dnainternet.fi] has joined #wesnoth-dev
20160717 08:05:38 * Aginor sighs
20160717 08:05:39< Aginor> plugins.set_callback("exit", std::bind(&safe_exit, std::bind(get_int, std::placeholders::_1, "code", 0)), false);
20160717 08:06:06< Aginor> I don't particurly like that line ;)
20160717 08:08:06< Aginor> can someone explain what we use safe_exit for?
20160717 08:08:33-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160717 08:10:52-!- mjs-de [~mjs-de@x4e305225.dyn.telefonica.de] has joined #wesnoth-dev
20160717 08:11:29< Aginor> as in, why do we use safe_exit instead of using it to throw an exception that's propagated all the way up?
20160717 08:11:39< Aginor> or would it be eaten by a handler somewhere in lua?
20160717 08:14:10-!- Kwandulin [~Miranda@p200300760F2D81C6A45AFBB79C8F2BC7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160717 08:17:04< vultraz> i dunno
20160717 08:17:06< vultraz> ask iceiceice 
20160717 08:23:25-!- mjs-de [~mjs-de@x4e305225.dyn.telefonica.de] has quit [Remote host closed the connection]
20160717 08:23:27< vultraz> especially since it says plugins
20160717 08:24:03< Aginor> I'd rather see us throwing an exception in that function and catching it in our main method, logging it and executing that way
20160717 08:24:12< Aginor> that'll also be RAII friendly
20160717 08:26:37-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160717 08:33:25-!- irker691 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160717 08:33:25< irker691> wesnoth: Andreas Löf wesnoth:Vultraz-event_handling_fixes 516daccbba37 / src/ (events.cpp wesnoth.cpp): Move the global event context onto the general event queue. https://github.com/wesnoth/wesnoth/commit/516daccbba373716fafd0acc58e224e1b927ac14
20160717 08:40:25-!- Kwandulin [~Miranda@p200300760F2D81C6A45AFBB79C8F2BC7.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160717 08:53:26< iceiceice> Aginor, you could probably do it that way
20160717 08:53:47< iceiceice> historically, i think wesnoth uses too many exceptions
20160717 08:54:00< iceiceice> and at one point i took a lot of effort to eliminate them
20160717 08:54:23< iceiceice> if the "safe_exit" is causing bugs somehow by causing something not to be destroyed, then yeah get rid of it
20160717 08:54:44< iceiceice> otherwise i dont know that its very easy to say which exceptions will or wont get eaten
20160717 08:55:55< Aginor> iceiceice: we could always introduce a new one
20160717 08:56:19-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160717 08:56:25< Aginor> I think I've worked around it for now, but I'm not sure what will happen if safe_exit is actually invoked
20160717 08:56:43< Aginor> but if I was to make bets, I would bet for crashes
20160717 08:56:52< iceiceice> i think std::safe_exit is supposed to call any handlers that were registered
20160717 08:56:58< iceiceice> and destroy statically initialized objects
20160717 08:57:07< iceiceice> i dont remember if it unwinds the stack
20160717 08:57:10< iceiceice> probably?
20160717 08:57:15< Aginor> hopefully
20160717 08:57:24< Aginor> ours doesn't though
20160717 08:57:39< Aginor> or maybe it does
20160717 08:57:41< iceiceice> abort is basically a crash
20160717 08:57:42< Aginor> I'm not sure
20160717 08:57:47< iceiceice> quick_exit is similar to abort i thik
20160717 08:58:23< Aginor> if travis passes I think we should merge this branch to master
20160717 08:59:21< Aginor> that way it'll be exercised more and we'll hopefully find out if we have any stability issues
20160717 08:59:43< iceiceice> i guess the stack is not unwound it says
20160717 08:59:58< iceiceice> so yea thats a good reason to use an exception instead
20160717 09:01:20< Aginor> hmmm
20160717 09:01:27< Aginor> it's probably safe though
20160717 09:01:31< Aginor> it'll just break RAII
20160717 09:01:51< Aginor> if it's used for any resources on disk and some such it'll not get cleaned up neatly
20160717 09:02:14< Aginor> so yeah, I'm in favour of making it an exception
20160717 09:02:46< Aginor> iceiceice: how do I test the exit callback in the plugin code?
20160717 09:02:55< iceiceice> i thinkt he bots do it
20160717 09:03:05< iceiceice> so like
20160717 09:03:08< iceiceice> in the root of repo
20160717 09:03:14< iceiceice> there are "join.lua" and "host.lua"
20160717 09:03:21< iceiceice> they both should call exit at the end of scripts iirc
20160717 09:03:43< Aginor> indeed
20160717 09:03:52< Aginor> can I invoke it manually from the lua console?
20160717 09:04:58< iceiceice> uhh
20160717 09:04:59< zookeeper> so, who all compile on VC other than aquileia?
20160717 09:05:01< iceiceice> i dont know
20160717 09:05:04< iceiceice> i dont think so
20160717 09:05:05< zookeeper> err, VS
20160717 09:05:11< iceiceice> i think you would have to make a little .lua scirpt like that
20160717 09:05:20< iceiceice> and convince wesnoth to load it using like --plugin my_script.lua
20160717 09:05:22< iceiceice> or something like that
20160717 09:05:25< iceiceice> syntax may have changed
20160717 09:05:29< Aginor> heh
20160717 09:05:35< Aginor> I have no idea how to do that ;)
20160717 09:05:58< iceiceice> what does the wesnoth program options look like now adays?
20160717 09:06:11< JyrkiVesterinen> zookeeper: I use VS2013.
20160717 09:06:15-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has joined #wesnoth-dev
20160717 09:06:16< travis-ci> wesnoth/wesnoth#9826 (Vultraz-event_handling_fixes - 516dacc : Andreas Löf): The build was fixed.
20160717 09:06:16< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/145321456
20160717 09:06:16-!- travis-ci [~travis-ci@ec2-54-205-165-154.compute-1.amazonaws.com] has left #wesnoth-dev []
20160717 09:06:39< Aginor>   --script arg                    (experimental) file containing a lua script 
20160717 09:06:46< iceiceice> thats probably it i guess
20160717 09:06:52< Aginor> or --plugin
20160717 09:06:57< iceiceice> hmmm
20160717 09:06:58< zookeeper> JyrkiVesterinen, oh, cool. did you happen to follow https://wiki.wesnoth.org/CompilingWesnothOnWindows#Visual_Studio ?
20160717 09:07:19< iceiceice> its probably in game_laucnher.cpp iirc
20160717 09:07:35< JyrkiVesterinen> zookeeper: Mostly.
20160717 09:07:49< iceiceice> i dont know if i remember the differnece
20160717 09:07:50< iceiceice> ohhh
20160717 09:07:56< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/game_launcher.cpp#L368
20160717 09:07:57< iceiceice> ok so
20160717 09:08:02< iceiceice> i think the main difference is
20160717 09:08:04< zookeeper> JyrkiVesterinen, ok, so, i believe you had to update the boost libraries, right? because the ones linked there won't work
20160717 09:08:11< iceiceice> script is something that must run to completion
20160717 09:08:18< iceiceice> it will block until it is finished basically
20160717 09:08:27< iceiceice> and there's no real way for it to register a handler or something
20160717 09:08:34< JyrkiVesterinen> Yes, I indeed updated the Boost libraries following the advice in the "external" repository.
20160717 09:08:37< iceiceice> so script is not suitable for most things, except like debugging
20160717 09:08:45< iceiceice> plugin is basically somehting that can be a lua coroutine
20160717 09:08:48< JyrkiVesterinen> I recall that I needed to improvise a bit, too.
20160717 09:08:59< iceiceice> at any point in time there may be like "n" plugin scripts that are active
20160717 09:09:04< iceiceice> they can run for a while and then yield
20160717 09:09:10< iceiceice> and then they will be called again at some ltaer slice
20160717 09:09:30< iceiceice> the two mp tests work like that
20160717 09:09:47< zookeeper> JyrkiVesterinen, okay... what "external" repository?
20160717 09:09:54< JyrkiVesterinen> https://github.com/aquileia/external
20160717 09:10:04< iceiceice> Aginor, i think you need to use a plugin
20160717 09:10:19< Aginor> iceiceice: yup
20160717 09:10:19< iceiceice> because judging from code comments i left two years ago,t he --script only runs in application lua kernel
20160717 09:10:23< zookeeper> JyrkiVesterinen, oh nevermind
20160717 09:10:26< Aginor> I've got it working and it's segfaulting
20160717 09:10:31< iceiceice> ok
20160717 09:10:38< Aginor> so yeah, I don't like our safe_exit ;)
20160717 09:10:42< iceiceice> yeah...
20160717 09:10:43< iceiceice> so 
20160717 09:10:53< iceiceice> maybe its like some threading issue?
20160717 09:10:58< Aginor> nah
20160717 09:11:03< iceiceice> because threads need to be joined right?
20160717 09:11:07< Aginor> let me grab a stacktrace
20160717 09:11:09< zookeeper> JyrkiVesterinen, right, i'll see if i can manage it...
20160717 09:11:16< iceiceice> maybe safe_exit is preventing the threads from being joined?
20160717 09:11:35< JyrkiVesterinen> zookeeper: Feel free to ask me for advice if you get stuck. :)
20160717 09:11:40< zookeeper> sure
20160717 09:12:20< iceiceice> idk
20160717 09:12:25< Aginor> iceiceice: I don't think it's a concurrency issue, it rather seems to be the order things are destroyed, or not
20160717 09:12:39< Aginor> $3 = {_vptr.sdl_handler = 0x30, has_joined_ = 33, has_joined_global_ = false}
20160717 09:12:51< Aginor> those boolean values shure look funny to me ;)
20160717 09:12:55< iceiceice> yeah
20160717 09:13:03< Aginor> so I think that that's a "use after free"
20160717 09:13:46< iceiceice> hmmm
20160717 09:14:03< Aginor> I'm not convinced I'm barking up the right tree here though
20160717 09:14:15< iceiceice> could try compiling with like
20160717 09:14:20< iceiceice> -fsanitize=undefined or something
20160717 09:14:41< Aginor> because that object should have had it's own destructor invoked and that should have removed it from the list if that was run before
20160717 09:14:48< Aginor> maybe I need to valgrind a bit
20160717 09:15:20-!- Kwandulin [~Miranda@p200300760F2D81C6B1514522D87A8AD1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160717 09:15:32-!- edgrey [~edgrey@178.204.86.66] has joined #wesnoth-dev
20160717 09:16:00< Aginor> yes, use after free
20160717 09:17:03< zookeeper> JyrkiVesterinen, actually, i'll pass and just wait for someone to update the dependency package. that's the sort of thing that always fails if i try to do it myself.
20160717 09:17:26< iceiceice> Aginor, did you try with changing out the safe_exit for exception?
20160717 09:17:36< iceiceice> because i think you are right that could mess up some of the dtor logic
20160717 09:18:19< Aginor> iceiceice: I haven't
20160717 09:18:36< Aginor> I'll try to track down the use-after-free instead
20160717 09:18:52< iceiceice> ok
20160717 09:18:52< iceiceice> gl
20160717 09:18:57< Aginor> thanks
20160717 09:19:20< Aginor> at least I have a clear-cut way to repro
20160717 09:19:27< Aginor> iceiceice: thanks for your help :)
20160717 09:19:35< iceiceice> yah np
20160717 09:22:35-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160717 10:06:56-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160717 10:07:02-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160717 10:07:16< irker691> wesnoth: Andreas Löf wesnoth:Vultraz-event_handling_fixes 501eb6074391 / src/ (events.cpp events.hpp): Fix crash in context destructor https://github.com/wesnoth/wesnoth/commit/501eb6074391f87bdfe5d670ef77450465e15499
20160717 10:08:36-!- Duthlet [~Duthlet@dslb-188-106-027-209.188.106.pools.vodafone-ip.de] has joined #wesnoth-dev
20160717 10:10:18< Aginor> that should do it
20160717 10:13:04< vultraz> Aginor: is the branch good?
20160717 10:14:42< Aginor> vultraz: travis will tell
20160717 10:14:47< Aginor> but please test more
20160717 10:14:50< vultraz> alright
20160717 10:14:54< vultraz> if it passes do we merge?
20160717 10:16:27-!- JyrkiVesterinen [~JyrkiVest@87-100-160-159.bb.dnainternet.fi] has quit [Quit: .]
20160717 10:16:56< Aginor> maybe have celticminstrel and someone look at it too
20160717 10:17:02< Aginor> no need to rush
20160717 10:19:38< vultraz> at least you fixed the pesky crash :)
20160717 10:19:42< vultraz> many kudos
20160717 10:19:50< vultraz> (let's hope that doesn't come back to bite me)
20160717 10:20:41< iceiceice> ah yes
20160717 10:20:51< iceiceice> that kind of bug
20160717 10:22:02< iceiceice> it reminds me of this bug report:
20160717 10:22:02< iceiceice> https://gna.org/bugs/index.php?21768
20160717 10:35:06< vultraz> everything seems to be working
20160717 10:35:46-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160717 10:43:23< Aginor> is that bug still not fixed?
20160717 10:49:54 * Aginor humms
20160717 10:51:56< vultraz> you know you have a slow project when bugs aren't fixed in 2 years
20160717 10:52:22< irker691> wesnoth: Andreas Löf wesnoth:Vultraz-event_handling_fixes 9550c3636ba8 / src/events.cpp: Ensure that focus handling stays the same as before the fix https://github.com/wesnoth/wesnoth/commit/9550c3636ba826991ef9e23a0ba7dc2ad4d9ac7a
20160717 10:52:29< Aginor> ok, now I'm happy
20160717 10:52:39< Aginor> let's give it a round of testing
20160717 10:52:43< vultraz> hm?
20160717 10:52:45< vultraz> why that change
20160717 10:52:47< Aginor> maybe rebase and squash a bit
20160717 10:53:00< Aginor> vultraz: because you changed the logic compared to what it was previously
20160717 10:57:41< vultraz> ah
20160717 10:57:46< vultraz> it seemed right at the time
20160717 10:58:54< Aginor> I disagreed when I diffed against master
20160717 10:58:56< Aginor> :D
20160717 10:59:26< vultraz> well it's your purview 
20160717 10:59:32< vultraz> so I'll defer 
20160717 10:59:54< Aginor> you've probably looked as much as I have on that code by now
20160717 11:00:59< vultraz> at least it's a little cleaner now
20160717 11:01:33< Aginor> there's scope for cleaning more
20160717 11:02:08< vultraz> well, we don't want to do anything deeper until renderpath fixes is done
20160717 11:02:15< Aginor> but I don't want to do that now as it might introduce further regressions that take days to fix
20160717 11:02:26< Aginor> vultraz: this is pretty much completely unrelated
20160717 11:03:18< vultraz> I see
20160717 11:08:31 * vultraz returns to drawing pixel art to the sounds of the Lord of the Rings soundtrack
20160717 11:09:43< Aginor> each one to their own
20160717 11:10:26< Aginor> vultraz: you wouldn't agree to my choice of work music, I'm sure :D
20160717 11:10:43< vultraz> death metal?
20160717 11:12:40-!- gfgtdf [~chatzilla@x4e3630e0.dyn.telefonica.de] has joined #wesnoth-dev
20160717 11:12:52< gfgtdf> zookeeper: i also use VC but i dont use that dependency package
20160717 11:13:41< Aginor> amongst others
20160717 11:14:05< vultraz> o_O
20160717 11:16:04< gfgtdf> zookeeper: an i also recomand to just build boost youself, i can help you with it, its not hard but it takes quite a while to complile.
20160717 11:21:25< gfgtdf> 20160717 10:22:02< iceiceice> https://gna.org/bugs/index.php?21768 20160717 10:43:23< Aginor> is that bug still not fixed?
20160717 11:21:29-!- Kwandulin [~Miranda@p200300760F2D81C6B1514522D87A8AD1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160717 11:22:14< gfgtdf> iceiceice, Aginor that might be fixed when i added  that game_lua_kernal::map_locked_ variable for when i added wesnoth.effects.
20160717 11:22:56< Aginor> gfgtdf: think you can be bothered to test and potentially mark as closed?
20160717 11:25:31< gfgtdf> Aginor: hmm maybe i'll do that
20160717 11:26:25-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160717 11:30:07< Aginor> thanks
20160717 11:35:37-!- JyrkiVesterinen [~JyrkiVest@87-100-192-170.bb.dnainternet.fi] has joined #wesnoth-dev
20160717 11:36:38-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160717 12:02:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 12:26:13-!- gfgtdf [~chatzilla@x4e3630e0.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160717 12:33:31-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Ping timeout: 240 seconds]
20160717 12:44:35-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160717 12:54:43-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160717 13:14:16-!- JyrkiVesterinen [~JyrkiVest@87-100-192-170.bb.dnainternet.fi] has quit [Quit: .]
20160717 13:24:01-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160717 13:26:43-!- edgrey [~edgrey@178.204.86.66] has quit [Remote host closed the connection]
20160717 13:33:20-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160717 13:35:31-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20160717 13:41:03-!- JyrkiVesterinen [~JyrkiVest@87-100-192-170.bb.dnainternet.fi] has joined #wesnoth-dev
20160717 13:52:43-!- irker691 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160717 13:54:58-!- Kwandulin [~Miranda@p200300760F2D81C6F945189F9B6571A7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160717 14:01:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160717 14:01:33-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 14:01:58-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160717 14:02:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 14:02:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160717 14:07:20-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160717 14:15:32-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 14:28:58-!- mjs-de [~mjs-de@x4e31a31f.dyn.telefonica.de] has joined #wesnoth-dev
20160717 14:32:30-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160717 14:38:11< zookeeper> JyrkiVesterinen, i take it that the monte carlo version doesn't have any actual drawbacks to it, except for a negligible accuracy loss?
20160717 14:39:19< JyrkiVesterinen> In addition to accuracy loss, it's usually slower. In my benchmarking tests, MC simulation took about 4 ms per battle, while exact calculation was ~200 us per battle.
20160717 14:39:34< zookeeper> ah, okay
20160717 14:46:24-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160717 14:48:31< zookeeper> the "as soon as another unit is moused over the stats for an attack will be calculated" part of the wiki entry sounds weird, though. why would they be calculated on mouseover, rather than when bringing up the window? to cache the results or something?
20160717 14:50:00< JyrkiVesterinen> I don't know. When debugging, I noticed that the calculation is performed both when I hover the unit, and when I open the damage calculation window. It's even recalculated if I open the window again.
20160717 14:50:28< JyrkiVesterinen> (Easy way to check if MC simulation is used: open the window twice. If simulation is used, the HP distributions will differ a bit.)
20160717 14:52:59< zookeeper> i can't really think of a reason
20160717 14:55:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160717 14:55:55-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has quit [Ping timeout: 250 seconds]
20160717 14:56:12-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160717 14:56:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 14:57:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160717 14:58:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 15:16:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160717 15:16:32-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 15:24:16-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160717 15:27:20-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160717 15:27:33-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160717 15:37:08-!- gfgtdf [~chatzilla@x4e3630e0.dyn.telefonica.de] has joined #wesnoth-dev
20160717 15:44:06< iceiceice> zookeeper, i think they were done that way because in default wesnoth it is always basically instant
20160717 15:44:25< iceiceice> i assume dave wrote it
20160717 15:44:34-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160717 15:45:04< celticminstrel> ?
20160717 15:45:06-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 15:45:31< iceiceice> JyrkiVesterinen, that is cool that you implemented this :)
20160717 15:46:07< gfgtdf> JyrkiVesterinen, zookeeper: from looking at the code it seems like the widescreen theme showhow prints the attacker result at mouseover
20160717 15:46:45-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160717 15:47:19-!- Appleman1234 [~Appleman1@KD036012050155.au-net.ne.jp] has left #wesnoth-dev ["Leaving"]
20160717 15:47:31< zookeeper> gfgtdf, right, that's probably the reason
20160717 15:47:45-!- Kwandulin [~Miranda@p200300760F2D81C6F945189F9B6571A7.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160717 15:47:51 * celticminstrel confused
20160717 15:49:04< zookeeper> i seem to recall that happening before. are you unable to view the logs from wherever you're connecting from, or something?
20160717 15:49:20-!- edgrey [~edgrey@178.204.86.66] has joined #wesnoth-dev
20160717 15:49:36< celticminstrel> Eh, I guess I can look at the logs...
20160717 15:49:36-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160717 15:50:16-!- Appleman1234 [~Appleman1@KD036012050155.au-net.ne.jp] has joined #wesnoth-dev
20160717 15:50:21< zookeeper> iceiceice, i don't know, but considering the calculations graph was added between 1.0 and 1.12 i think (?), it might not have been dave
20160717 15:50:30< zookeeper> err, s/1.12/1.2
20160717 15:51:23< iceiceice> yeah, i guess i have no real reason to assume it
20160717 15:51:41< iceiceice> i mean it hooks into the same damage calculations code as is used by the ai
20160717 15:51:49< iceiceice> so i assume dave wrote that
20160717 15:52:09< iceiceice> but the graph part, and the part about mouse over triggering a calculation, yeah maybe not
20160717 15:52:40< celticminstrel> Wait, what? Mouseover triggering a calculation?
20160717 15:54:15< zookeeper> and if it does the calculation on mouseover to allow showing the results as some kind of tool-tip like thing, it'd be nice if _that_ was 1) not done unless the results are actually shown and 2) threaded so it doesn't cause a delay anyway. sadly, nice doesn't equal easy.
20160717 15:54:58< JyrkiVesterinen> I can add that to my todo list.
20160717 15:55:50< iceiceice> i dont remember how the attack code works exactly
20160717 15:56:03< iceiceice> like if it requires pointers to other parts of the game state
20160717 15:56:23< iceiceice> i guess most of it can probably be copied out to make it thread-safe, but that might be a chore
20160717 15:56:56< iceiceice> but yeah threaded would probably make more sense
20160717 15:57:04< iceiceice> than the original implementation
20160717 15:58:11< JyrkiVesterinen> The damage prediction code keeps around pointers to the unit states, so it's not thread-state at the moment.
20160717 15:58:35< JyrkiVesterinen> Another possibility would be to cancel the calculation if the unit state changes.
20160717 16:03:12< celticminstrel> So, did Aginor manage to get the MP test working?
20160717 16:04:59< celticminstrel> Also, are we putting the splice back?
20160717 16:09:33-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Ping timeout: 240 seconds]
20160717 16:17:33< celticminstrel> Seems like the server crash is not related to the failure to load the plugins...
20160717 16:19:33< celticminstrel> The plugin just keeps going after the server has crashed, which seems weird. Can this be fixed?
20160717 16:22:32-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:892e:7d4f:415f:f682] has joined #wesnoth-dev
20160717 16:24:55-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has joined #wesnoth-dev
20160717 16:25:29< celticminstrel> ...where does the "playing multiplayer" message come from...
20160717 16:26:54-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:892e:7d4f:415f:f682] has quit [Ping timeout: 250 seconds]
20160717 16:34:51-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160717 16:35:00-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160717 16:36:20-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160717 16:36:27-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160717 16:37:19-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160717 16:37:21< iceiceice> celticminstrel, i think its from either `join.lua` or `host.lua`
20160717 16:37:45< celticminstrel> I was looking through those and didn't see it.
20160717 16:37:50< iceiceice> hmmm
20160717 16:38:39< iceiceice> yeah i was wrong
20160717 16:38:46-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160717 16:39:30< celticminstrel> Doesn't seem to be from any C++ code though...
20160717 16:40:29< iceiceice> is it in one of the bash scripts?
20160717 16:47:43-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160717 16:50:43-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160717 16:52:39-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160717 16:52:58-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 252 seconds]
20160717 16:52:58-!- wedge010 is now known as wedge009
20160717 16:58:15-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160717 17:00:18-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160717 17:00:19-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160717 17:01:11-!- mjs-de [~mjs-de@x4e31a31f.dyn.telefonica.de] has quit [Remote host closed the connection]
20160717 17:23:20-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160717 17:23:26-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160717 17:30:45-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160717 17:30:51-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160717 17:45:45-!- edgrey [~edgrey@178.204.86.66] has quit [Remote host closed the connection]
20160717 17:46:07-!- edgrey [~edgrey@178.204.86.66] has joined #wesnoth-dev
20160717 17:58:58-!- Kwandulin [~Miranda@p200300760F2D81C6949C9B67D9A806A6.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160717 18:09:19-!- edgrey [~edgrey@178.204.86.66] has quit [Remote host closed the connection]
20160717 18:09:52-!- edgrey [~edgrey@178.204.86.66] has joined #wesnoth-dev
20160717 18:09:53-!- Shiki [~Shiki@141.39.226.227] has quit [Quit: Verlassend]
20160717 18:19:31< mattsc> celticminstrel: I’m now done reading all the new content.
20160717 18:19:38< mattsc> The aspect section looks goo.  I have nothing significant to say, just a few minor comments:
20160717 18:19:48< mattsc> 1. I think the main confusing thing for somebody new to this is that the section on simple aspects refers to terms from the composite aspects (e.g. facets) a couple times before those are defined.  But other than adding a “(see below)” or something, I don’t really see what can be done about that.
20160717 18:19:49< mattsc> I also don’t think that it’s very important.  Anybody who seriously wants to understand the details has to read the whole thing several times anyway.  And for most uses, there’s the AiWML page anyway.
20160717 18:19:57< mattsc> 2. Second example for the [candidate_action] tag: [params] should be [args], shouldn’t it?
20160717 18:19:57< mattsc> 3. The first “here” link right before the [facet] tag bullet is broken
20160717 18:19:58< mattsc> 4. Does the new implementation of ai_algorithm fix https://gna.org/bugs/?16107 ?
20160717 18:19:59< mattsc> 5. There were also a couple very minor typos, I just fixed those myself.
20160717 18:29:41-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160717 18:31:42-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has quit [Ping timeout: 260 seconds]
20160717 18:43:50-!- prkc [~prkc@46.166.138.157] has joined #wesnoth-dev
20160717 18:50:11-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160717 18:50:26-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160717 18:53:15-!- prkc [~prkc@46.166.138.157] has quit [Ping timeout: 264 seconds]
20160717 18:54:30-!- Netsplit *.net <-> *.split quits: JyrkiVesterinen, zookeeper, Gambit, bumbadadabum
20160717 19:04:14-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160717 19:04:33-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160717 19:06:00-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20160717 19:07:35-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has joined #wesnoth-dev
20160717 19:10:21-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160717 19:13:29-!- Netsplit over, joins: Gambit
20160717 19:13:42-!- Netsplit over, joins: zookeeper
20160717 19:14:03-!- Netsplit over, joins: bumbadadabum, JyrkiVesterinen
20160717 19:17:26< celticminstrel> mattsc: I don't understand why that link is broken - it's linking to an existing page. I'll fix the incorrect use of [params] and take a look at that bug.
20160717 19:27:21< celticminstrel> gfgtdf, vultraz: Any objections to merging PR661 now?
20160717 19:27:36< celticminstrel> Beyond conflicts and cleanup and such.
20160717 19:29:45< gfgtdf> celticminstrel: I don't really care that much about random map labels in map generators, specially becasue the most used map generator scenario (word conquest (2)) doesn't use them.
20160717 19:30:46-!- stikonas_ is now known as stikonas
20160717 19:32:05-!- Kwandulin [~Miranda@p200300760F2D81C6949C9B67D9A806A6.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160717 19:32:57< mattsc> celticminstrel: I fixed the link; capitalization typo
20160717 19:33:17< celticminstrel> Aha... okay then.
20160717 19:40:13< celticminstrel> mattsc: I'm not sure if that bug is addressed; I haven't done any testing in that direction.
20160717 19:41:24< celticminstrel> I suspect that [modify_side][ai]ai_algorithm=idle_ai might simply add a new empty stage (since that's the definition of the idle AI) without removing any existing stages. Naturally, this would have no effect on the AI behaviour.
20160717 19:42:20< celticminstrel> I could probably modify the behaviour of [modify_side][ai] so that the presence of an ai_algorithm key causes the AI definition to be replaced instead of appeneded; or add some way to more explicitly specify to replace instead of append, or something.
20160717 19:48:49< celticminstrel> Oh, I was wrong, apparently "playing multiplayer" is in host/join.lua.
20160717 19:49:25< celticminstrel> Ah, that's why I didn't find it - it's printed while the bot idles at the titlescreen, so it's kinda misleading.
20160717 19:50:24< celticminstrel> Hmm. Does context.play_multiplayer{} return any meaningful result which could be used to detect that the server is unavailable?
20160717 19:52:59< celticminstrel> The C++ function is of type bool() ... how does it map into Lua...
20160717 19:55:56< celticminstrel> It's hard to tell, but I'm getting the impression that "callbacks" always return no value to the Lua code.
20160717 19:56:37< celticminstrel> So maybe the test should give up after attempting to connect, say, 100 times?
20160717 19:56:48< celticminstrel> I guess iceiceice is no longer around for input.
20160717 19:59:56< celticminstrel> Well, that does appear to work, in that the plugins do not keep going forever.
20160717 20:00:13< celticminstrel> I still don't know why it's crashing, though.
20160717 20:00:28< celticminstrel> The clients are sending bad data, or something?
20160717 20:04:40< celticminstrel> Hmm, the top user stack frame is simple_wml.cpp:64, but...
20160717 20:05:15< celticminstrel> Backing out of simple_wml gets me to server.cpp:167, in async_send_doc, and...
20160717 20:05:37< celticminstrel> Backing out of that brings me to server.cpp:788 in server::request_version.
20160717 20:06:08-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160717 20:06:09-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160717 20:06:15< celticminstrel> loonycyborg: Any ideas?
20160717 20:08:31< loonycyborg> celticminstrel: how exactly do you repro it?
20160717 20:09:25< celticminstrel> I'm trying to run the MP test that Travis uses on my computer, but the server is throwing some sort of IO exception.
20160717 20:09:45< celticminstrel> It's consistent on my computer; I dunno if it would be consistent on other systems.
20160717 20:10:30< celticminstrel> The shell-script is at utils/travis/mp_test_executor.sh.
20160717 20:10:56< loonycyborg> so you just run it without any changes compared to master and it crashes?
20160717 20:11:01< celticminstrel> Right.
20160717 20:11:27< loonycyborg> and it's part of travis run at least for some configurations
20160717 20:11:35< celticminstrel> I did change host.lua and join.lua, but that had no effect on the crash (it just caused the clients to give up instead of continuing to try connecting).
20160717 20:11:56< celticminstrel> Yeah, and I think it's usually successful on Travis?
20160717 20:12:06< loonycyborg> and you're running it on macos?
20160717 20:12:15< celticminstrel> Yes, 10.7 to be precise.
20160717 20:12:51< loonycyborg> hmm if it crashes in async_send_doc then it's unlikely that it's caused by bad client data
20160717 20:12:56< loonycyborg> unless it's another UB
20160717 20:13:29< bumbadadabum> error scripting/lua: ai/lua/ai_helper.lua:132: ai.recruit of Chaos Raider could not be executed. Error code: 3004
20160717 20:13:31< bumbadadabum> w-what does this mean
20160717 20:14:16< celticminstrel> bumbadadabum: Uh... that is... a very good question.
20160717 20:14:49< celticminstrel> I should probably know the answer...
20160717 20:14:53< bumbadadabum> I just have the rushers AI set up for the side
20160717 20:14:57< bumbadadabum> and for another side
20160717 20:15:03< bumbadadabum> and for that other side it works fine
20160717 20:16:37< loonycyborg> celticminstrel: maybe try recompiling it with -fsanitize=address?
20160717 20:17:04< loonycyborg> both to compiler and linker
20160717 20:17:09< celticminstrel> The server?
20160717 20:17:12< loonycyborg> yes
20160717 20:17:28< loonycyborg> then at runtime it would be able to detect invalid memory accesses
20160717 20:18:10< loonycyborg> celticminstrel: hmm but I missed one thing
20160717 20:18:10< mattsc> bumbadadabum: https://github.com/wesnoth/wesnoth/blob/master/src/ai/actions.hpp#L246
20160717 20:18:18< loonycyborg> what exact type of crash you;'re getting?
20160717 20:18:26< loonycyborg> segfault, assert?
20160717 20:18:44< celticminstrel> Exception. I said that, didn't I?
20160717 20:19:08< bumbadadabum> mattsc: but it has a leader
20160717 20:19:39< loonycyborg> hmm didn't see that in log
20160717 20:19:42-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160717 20:19:42< loonycyborg> which exception?
20160717 20:20:19< celticminstrel> I think it's zlib_error from Boost.Iostreams.
20160717 20:20:48< celticminstrel> The xinflate() function returned -3, last I checked.
20160717 20:24:27< loonycyborg> hmm interesting
20160717 20:28:37< loonycyborg> it means that zlib returns error when server compresses data
20160717 20:28:41< loonycyborg> before sending it
20160717 20:29:15< loonycyborg> but I have no idea what exactly server could do to make zlib error out
20160717 20:37:15< celticminstrel> Inflate is compression? It sounds more like decompression to me.
20160717 20:39:16-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160717 20:51:26-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
20160717 20:55:58< loonycyborg> inflate is compression, deflate is decompression :P
20160717 20:56:10< loonycyborg> or wait
20160717 20:56:15< loonycyborg> got confused
20160717 21:07:16< Aginor> celticminstrel: I did get all things resolved yesterday
20160717 21:09:27-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160717 21:10:47< celticminstrel> Okay.
20160717 21:11:00< celticminstrel> I think the crash I'm getting is probably unrelated.
20160717 21:13:37< Aginor> celticminstrel: I think so too, I managed to reproduce and fix the one travis showed me
20160717 21:13:51< Aginor> that doesn't mean your crash isn't important though
20160717 21:17:20< celticminstrel> I still haven't gotten the unit tests to work in XCode, either...
20160717 21:17:37< celticminstrel> I got them to compile and link, but that's as far as I got.
20160717 21:18:52< Aginor> hmm
20160717 21:19:04< Aginor> whewn you're at that stage they really ought to be working
20160717 21:19:44< celticminstrel> Yeah, I dunno. There were dyld issue (I think I did eventually resolve those though) and a crash someplace.
20160717 21:21:39< Aginor> fair enough
20160717 21:22:13< Aginor> I'd offer to have a look, but I'm all out of working machines running OS X and I'm not going to go and buy a new one :/
20160717 21:22:22-!- irker911 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160717 21:22:22< irker911> wesnoth: Celtic Minstrel wesnoth:master 20b7e5b757e4 / host.lua join.lua: MP Test: Give up after 100 tries https://github.com/wesnoth/wesnoth/commit/20b7e5b757e445712e10a2245d536d991edfbba6
20160717 21:25:02< loonycyborg> celticminstrel: is it intel mac? I don't think I tested it on a system with different byteorder
20160717 21:25:15< loonycyborg> though probably it is
20160717 21:25:18< celticminstrel> Yeah, it's intel.
20160717 21:26:06< celticminstrel> Though with ten-year-old macs you can't really assume that. :P
20160717 21:27:46-!- JyrkiVesterinen [~JyrkiVest@87-100-192-170.bb.dnainternet.fi] has quit [Quit: Going to bed]
20160717 21:46:00-!- mjs-de [~mjs-de@x4e31a31f.dyn.telefonica.de] has joined #wesnoth-dev
20160717 21:46:59-!- Nobun [~nobun@host188-51-dynamic.6-87-r.retail.telecomitalia.it] has joined #wesnoth-dev
20160717 22:04:50< celticminstrel> Unit tests have more link errors now.
20160717 22:05:23< celticminstrel> Are network.?pp and network_worker.?pp still used?
20160717 22:05:42< celticminstrel> The XCode project doesn't seem to be referencing them, but some tests use at least the former.
20160717 22:05:51< celticminstrel> Probably both.
20160717 22:06:05< celticminstrel> loonycyborg, gfgtdf?
20160717 22:06:07-!- mjs-de [~mjs-de@x4e31a31f.dyn.telefonica.de] has quit [Remote host closed the connection]
20160717 22:06:44< loonycyborg> celticminstrel: they're needed for campaignd 
20160717 22:07:00< celticminstrel> I see...
20160717 22:07:15< loonycyborg> campaignd_asio branch gets rid of that dep
20160717 22:07:23< celticminstrel> I could remove the tests referencing them from the XCode project.
20160717 22:07:26< loonycyborg> for tests too
20160717 22:08:21< celticminstrel> Unless those tests have other stuff that's not dependent on them.
20160717 22:14:27< celticminstrel> Looking at the branch, I don't see any deleted files, nor any edited tests.
20160717 22:15:42< celticminstrel> Seems the only test is test_network_worker.cpp
20160717 22:21:44-!- Nobun [~nobun@host188-51-dynamic.6-87-r.retail.telecomitalia.it] has quit [Quit: Salve a tutti]
20160717 22:45:35< irker911> wesnoth: Celtic Minstrel wesnoth:master 63e0303c0073 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update XCode project so that unit tests build https://github.com/wesnoth/wesnoth/commit/63e0303c0073573c577d6f7fe7f74d3380bb0ef0
20160717 22:46:19< celticminstrel> They're still mysteriously crashing in boost::filesystem::path::operator/= though.
20160717 22:46:56< celticminstrel> Called from operator/, called from filesystem::set_user_data_dir
20160717 23:15:27-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20160717 23:27:48-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160717 23:28:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds]
20160717 23:33:44-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has quit [Ping timeout: 250 seconds]
20160717 23:34:05-!- Duthlet [~Duthlet@dslb-188-106-027-209.188.106.pools.vodafone-ip.de] has quit [Quit: leaving]
20160717 23:45:08< bumbadadabum> oh uhh
20160717 23:45:44< bumbadadabum> narrator messages without an image give a lua error
20160717 23:45:49< celticminstrel> Oh my.
20160717 23:45:52< celticminstrel> On master?
20160717 23:45:54< bumbadadabum> yes
20160717 23:45:59< bumbadadabum> let me see if I fixed it
20160717 23:46:04< celticminstrel> Huh?
20160717 23:46:13< celticminstrel> You might have fixed it?
20160717 23:46:16< bumbadadabum> it sets image to the portrait of the speaker
20160717 23:46:25< bumbadadabum> but if the speaker is narrator image is still a nil
20160717 23:46:35< bumbadadabum> then it tries to do image:find
20160717 23:46:43< bumbadadabum> which obviously doesn't work if the image is ni
20160717 23:46:45< bumbadadabum> *nil
20160717 23:46:53< bumbadadabum> so I just added if image to the if clause
20160717 23:46:54< celticminstrel> Hmm.
20160717 23:47:11< vultraz> sounds like that works
20160717 23:47:15-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has joined #wesnoth-dev
20160717 23:47:23< vultraz> or one could do image = speaker.portrait or "" I guess?
20160717 23:47:24< celticminstrel> I think moving blocks of code around might be better.
20160717 23:48:26< celticminstrel> Also, I'm pretty sure line 36 is supposed to return left_side, not true...
20160717 23:48:40< celticminstrel> Oh, right, if there's no image I guess it doesn't matter.
20160717 23:48:45< bumbadadabum> yeah
20160717 23:48:50< bumbadadabum> I could just do an early return
20160717 23:48:53< bumbadadabum> that might be better
20160717 23:48:54< celticminstrel> Anyway, I think moving the image find to the end would work?
20160717 23:49:56< bumbadadabum> I think this is the best way to do it
20160717 23:49:59< irker911> wesnoth: Bär Halberkamp wesnoth:master 0a83e2e6b661 / data/lua/wml/message.lua: Fix [message]s without an image not working https://github.com/wesnoth/wesnoth/commit/0a83e2e6b661167c85391d30da5753555da38c60
20160717 23:50:41< celticminstrel> Yeah, I was going to suggest something like that.
20160717 23:51:28< irker911> wesnoth: Celtic Minstrel wesnoth:master 36eeed413c08 / data/lua/wml/message.lua: Comment fixup https://github.com/wesnoth/wesnoth/commit/36eeed413c08f9d2a5abc84976ca7637dc8bbd0d
20160717 23:51:52< bumbadadabum> oh oops
20160717 23:51:57< bumbadadabum> I never read comments my bad
20160717 23:52:38< bumbadadabum> wesnoth: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = name_generator; typename boost::detail::sp_member_access<T>::type = name_generator*]: Assertion `px != 0' failed.
20160717 23:52:42< bumbadadabum> hmm what does this error mean
20160717 23:53:21< celticminstrel> It means a name generator has not been constructed in someplace where it was expected.
20160717 23:53:47< celticminstrel> I thought vultraz fixed something like that before.
20160717 23:53:52< vultraz> I did?
20160717 23:53:59< celticminstrel> Huh? You didn't?
20160717 23:54:07< vultraz> I'm asking you
20160717 23:54:16< celticminstrel> There was a bug that I thought might be fixed by 661, but we realized it wasn't, so I thought you went and fixed it?
20160717 23:54:22 * celticminstrel checks commit log.
20160717 23:54:40< vultraz> Uh
20160717 23:54:49< vultraz> That's with randomly generated maps
20160717 23:55:10< celticminstrel> Well, I have no idea where bumbadadabum got the error. Could be with random maps, or with unit name generation, I dunno.
20160717 23:55:25< bumbadadabum> I tried to load LotI (don't ask me why)
20160717 23:55:47< celticminstrel> BTW vultraz, any objections to merging PR661 other than conflicts/cleanup?
20160717 23:56:05< vultraz> i don'r really understand what he did to fix the issue
20160717 23:56:07< celticminstrel> I asked earlier but you weren't around.
20160717 23:57:24< vultraz> is it the {|} thing?
20160717 23:57:46< celticminstrel> Basically. He went with something like that.
20160717 23:57:54< celticminstrel> {!} means |
20160717 23:58:45< vultraz> for variable substitution or the generator?
20160717 23:58:55< celticminstrel> In the generator, {!} expands to |
20160717 23:59:03< vultraz> blah
20160717 23:59:06< celticminstrel> So basically, when you need a literal |, you use {!} instead.
20160717 23:59:20< vultraz> ya know, I really dislike creating all these special characters
--- Log closed Mon Jul 18 00:00:01 2016