--- Log opened Thu Sep 06 00:00:15 2018
20180906 00:10:54-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180906 00:11:00-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180906 00:24:47-!- louis94 [~~louis94@109.49-136-217.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds]
20180906 00:38:39< irker270> wesnoth/wesnoth:1.14 gfgtdf ca6e7aef7d fix #3515 : random start time AppVeyor: vs2017/Release Failed
20180906 00:38:40< irker270> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-1.14-4436
20180906 00:58:43< irker270> wesnoth/wesnoth:master newfrenchy83 1497bf8874 Update udisplay.cpp AppVeyor: All builds passed
20180906 01:19:26-!- behalebabo [~behalebab@unaffiliated/behalebabo] has quit [Ping timeout: 252 seconds]
20180906 01:24:09-!- behalebabo [~behalebab@unaffiliated/behalebabo] has joined #wesnoth-dev
20180906 03:08:08-!- celmin|sleep [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20180906 03:59:34-!- irker270 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout]
20180906 05:01:16-!- irker176 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20180906 05:01:16< irker176> wesnoth/wesnoth:master Severin Glöckner b9396cd116 fix syntax error in Chinese manual AppVeyor: All builds passed
20180906 05:04:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20180906 05:38:39< irker176> wesnoth/wesnoth:1.14 gfgtdf ca6e7aef7d fix #3515 : random start time AppVeyor: 2/4 builds failed
20180906 05:38:40< irker176> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-1.14-4436
20180906 05:38:41< irker176> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-1.14-4723
20180906 05:54:43-!- louis94 [~~louis94@109.49-136-217.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20180906 05:58:46-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20180906 06:04:06-!- louis94 [~~louis94@109.49-136-217.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 252 seconds]
20180906 06:49:12-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20180906 08:17:53-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20180906 08:46:04< irker176> wesnoth/wesnoth:master mattsc 43afb4ab75 Lua AIs: use ai_helper get_unit function AppVeyor: All builds passed
20180906 10:24:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180906 10:24:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180906 11:46:20-!- irker176 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout]
20180906 12:35:37-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20180906 12:50:28-!- valdar [~atarocch@93.56.164.28] has quit [Ping timeout: 245 seconds]
20180906 12:50:53-!- valdar [~atarocch@93.56.164.28] has joined #wesnoth-dev
20180906 16:36:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180906 17:14:34-!- irker010 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20180906 17:14:34< irker010> wesnoth: Jyrki Vesterinen wesnoth:1.14 5512eb6a1449 / src/ (color.hpp map/location.hpp): Fix build with Visual Studio 2013 https://github.com/wesnoth/wesnoth/commit/5512eb6a14499fc1646d93f021d180317870e985
20180906 17:14:34< irker010> wesnoth: Jyrki Vesterinen wesnoth:1.14 40b5e8da01c7 / src/saved_game.cpp: Fix build https://github.com/wesnoth/wesnoth/commit/40b5e8da01c7c4aef928f999da0f77ce2c402b5c
20180906 17:14:35< irker010> wesnoth: Jyrki Vesterinen wesnoth:1.14 4666ae8c2334 / data/lua/wml/animate_unit.lua: [animate_unit]: clear the animation after playing it https://github.com/wesnoth/wesnoth/commit/4666ae8c2334b73912cb96f42705c2f61e0a1893
20180906 17:16:12-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20180906 17:16:21< irker010> wesnoth: gfgtdf wesnoth:master 8ed601461eac / src/saved_game.cpp: fix #3515 : random start time https://github.com/wesnoth/wesnoth/commit/8ed601461eac824f96eb9e6c02cf07a7fcf16f48
20180906 17:16:23< irker010> wesnoth: Jyrki Vesterinen wesnoth:master 9f43c4a10e53 / src/saved_game.cpp: Fix build https://github.com/wesnoth/wesnoth/commit/9f43c4a10e536ef1ce496ac7371c8c8956d09445
20180906 17:16:25< irker010> wesnoth: Jyrki Vesterinen wesnoth:master e63bd35f9d20 / data/lua/wml/animate_unit.lua: [animate_unit]: clear the animation after playing it https://github.com/wesnoth/wesnoth/commit/e63bd35f9d209f355400a743732ea2c4b91d5da4
20180906 18:37:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180906 18:37:13-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180906 19:12:30-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180906 19:12:36-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180906 19:34:37-!- louis94 [~~louis94@109.49-136-217.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20180906 20:16:44-!- irker010 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout]
20180906 20:38:45-!- irker396 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20180906 20:38:45< irker396> wesnoth/wesnoth:master mattsc 60c174ca8c generic_recruit_engine: remove unnecessa AppVeyor: All builds passed
20180906 21:11:41-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20180906 21:14:09-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20180906 21:14:29-!- gfgtdf [~Daniel@x4dbb4de7.dyn.telefonica.de] has joined #wesnoth-dev
20180906 21:15:49< mattsc> gfgtdf: hi
20180906 21:15:58< gfgtdf> hi
20180906 21:16:12< mattsc> I’m not entirely sure why you have an “of course” in that last comment.
20180906 21:16:25< mattsc> On the Lua AI PR, I mean/.
20180906 21:17:35< mattsc> As in, what aspect that makes the first faster you are referring to.
20180906 21:18:31< mattsc> (I have a related question to that for you later, because something I found when doing speed testing of SUFs contradicts whar I think I remember you saying previously.)
20180906 21:20:18< gfgtdf> hmm let me think of an example
20180906 21:20:46< mattsc> I can think of examples that would make it faster, but you seem to say that it is always ftaser.
20180906 21:21:20< mattsc> So, let me maybe throw my other question out there first.
20180906 21:21:57< mattsc> I thought you had said that [and] tags in unit filters get evaluated before the keys.  Do I remember that incorrectly?
20180906 21:23:25< gfgtdf> hmm, no i think think that's correct. Also terrain filters for diffrently than unit filters.
20180906 21:24:59< gfgtdf> also location filter might (performance wise) behave differntly when called for single locations matches or with 'get_locations'. 
20180906 21:26:11< gfgtdf> currently [and] is get_locations wil iirc impleented as an intersection, so get_location( <filter1>, [and] <filter2> [/and]) will more or less, call get_location( <filter1>), get_location( <filter2>) and return the intersection of those two
20180906 21:26:30< mattsc> Okay, that’s inconsistent with what I found then; either that, or I am misunderstanding something.
20180906 21:26:56< gfgtdf> and if we take in  the opimisation opf x,y and other 'simple' keys ge tget the follwong example:
20180906 21:27:41< gfgtdf> the filter get_locatios(x=4, y=4, terrain="Ww^") will, due to the opiniotion of x,y filters, only check the terrain at 4,4
20180906 21:28:26< gfgtdf> the filter get_locatios(x=4, y=4, [and] terrain="Ww^" [/and]) will basicialyl call get_locatios(x=4, y=4), get_locatios(terrain="Ww^") and intersect, so all locations on the map are checkerd
20180906 21:28:59< gfgtdf> for that terrain= filter
20180906 21:29:31< mattsc> Okay.  I haven’t tested SLFs yet (at least not recently), but let me give you an example of what I found for SUFs.
20180906 21:30:21< mattsc> So I have an SUF that has a slow part to it inside an [and] tag.  (I usually do that in practice by using something like formula=$this_unit.moves in it)
20180906 21:30:33< mattsc> I put 100 units on my test map.
20180906 21:30:41< gfgtdf> SUF (currently, 1.14, we shodul realyl improce SLF) work differntly, in particular the [and] won'T be evauluates of the 'first' filter already returned false-
20180906 21:31:13< mattsc> Right.  But [and] should be evaluated before the keys?
20180906 21:31:35< mattsc> That’s the part I am really asking about.
20180906 21:32:08< gfgtdf> hmm, no if i understood our question correctly [and] si evalualted after they keays, so you should put the slow part in [and]
20180906 21:32:24< mattsc> Ah, okay.
20180906 21:32:57< mattsc> That’s consistent with what I find then.  (but I thought I remembered you saying it differently; probably my recollection is bad)
20180906 21:33:14< mattsc> So back to the SLFs:
20180906 21:33:52< mattsc> So why would your former example in your comment to the PR always be faster than the latter?  (“always” because that’s how I interpret the “of course”)
20180906 21:34:57< mattsc> As I said, I can come up with example for which it will be faster, but also with other for which I expect it would be slower.
20180906 21:35:13< gfgtdf> well as is said, becasue of how [and] works, in get_locations [and] basicialyl internally results in two get_locatiosn calls that then does in intersections, which is slower than doing it in one get_location call. 
20180906 21:35:43< mattsc> Hmm, okay.
20180906 21:35:43< gfgtdf> i am not sying that this difference is important in every case of course. 
20180906 21:35:55< mattsc> Right.
20180906 21:36:11< mattsc> I’d of course rather avoid having a function modify it’s input filter.
20180906 21:36:25< mattsc> But there are ways around that that have little overhead.
20180906 21:38:09< mattsc> There’s also a moethod that has no overhead (not using a function), which is what I might go back to.
20180906 21:38:19< gfgtdf> mattsc: well then just test, as im my first example i do think the fdifference between putting it into an [and] does make a give differnce for the cas where the x,y=3,4 contains a just a few tiles, but for include_borders= it migth not be important
20180906 21:39:11< gfgtdf> btw is this a master-only pr or will it also go into 1.14 ?
20180906 21:39:13< mattsc> gfgtdf: I bet you are right that there will be cases when it will make a difference.
20180906 21:39:33< mattsc> I’ll test it and report back.
20180906 21:39:48< mattsc> The PR is master only.
20180906 21:40:07< mattsc> But a speed improvement like that should probably be cherry-picked to 1.14.
20180906 21:40:26< gfgtdf> because if its master only there is a slight change that if i have the time, will change the location filter implemtation so fix what i just told you.
20180906 21:41:52< mattsc> gfgtdf: okay - but there’s still no reason why I should need the loop method in my current commit rather than using includer_borders= right?
20180906 21:43:13< mattsc> And as long as the [and] tags do not get evaluated before the keys, your suggested way should still be fastest on average.
20180906 21:44:06< mattsc> Since these are general use Micro AIs, the goal is not to tweak the most out of already fast filters, but to prevent slow filters from slowing things down to much.
20180906 21:45:04< gfgtdf> hmm not sure, it'S best to test it i think.
20180906 21:45:14< mattsc> Agreed.  Will do.
20180906 21:47:27< gfgtdf> i mean, asympoticially your lua code might be even faster depending on how the 'taking intersection' code is implemented on the c++ side, on the other hand, lua is generally slower than c++, 
20180906 21:48:33< mattsc> Could be.  But either method will be significantly faster than how it was before.
20180906 21:48:56< mattsc> Anyways, I’ll do some tests when I get around to them and let you know.
20180906 21:49:02< gfgtdf> actually i think that, if we ignore the fact that c++ code is faster than lua code, your lua loop is performance wise betwwen the insertion of include_border=no and the include_border=no, [and] <filter>  .
20180906 21:50:36< mattsc> Yeah, that makes sense, thinking about how many hexes need to be considered for each.
20180906 21:51:43-!- louis94 [~~louis94@109.49-136-217.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds]
20180906 22:00:03-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180906 22:00:09-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180906 22:01:32< mattsc> gfgtdf: one more question for clarification:  in your second example, did you mean to add the ‘include_borders’= false’ to ‘filter’ also or is that a cut-and-paste typo?
20180906 22:12:26-!- travis-ci [~travis-ci@ec2-54-81-49-114.compute-1.amazonaws.com] has joined #wesnoth-dev
20180906 22:12:27< travis-ci> hryniuk/wesnoth#6 (no-advance-info - 615b102 : Łukasz Hryniuk): The build has errored.
20180906 22:12:27< travis-ci> Build details : https://travis-ci.com/hryniuk/wesnoth/builds/84060315
20180906 22:12:27-!- travis-ci [~travis-ci@ec2-54-81-49-114.compute-1.amazonaws.com] has left #wesnoth-dev []
20180906 22:22:51-!- travis-ci [~travis-ci@ec2-54-227-21-128.compute-1.amazonaws.com] has joined #wesnoth-dev
20180906 22:22:52< travis-ci> hryniuk/wesnoth#7 (no-advance-info - eb02d32 : Łukasz Hryniuk): The build has errored.
20180906 22:22:52< travis-ci> Build details : https://travis-ci.com/hryniuk/wesnoth/builds/84061021
20180906 22:22:52-!- travis-ci [~travis-ci@ec2-54-227-21-128.compute-1.amazonaws.com] has left #wesnoth-dev []
20180906 22:24:05< gfgtdf> mattsc, in which second example? on the github comment ?
20180906 22:24:37-!- travis-ci [~travis-ci@ec2-54-83-120-59.compute-1.amazonaws.com] has joined #wesnoth-dev
20180906 22:24:38< travis-ci> hryniuk/wesnoth#5 (no-advance-info - eff0df9 : Łukasz Hryniuk): The build has errored.
20180906 22:24:38< travis-ci> Build details : https://travis-ci.com/hryniuk/wesnoth/builds/84060073
20180906 22:24:38-!- travis-ci [~travis-ci@ec2-54-83-120-59.compute-1.amazonaws.com] has left #wesnoth-dev []
20180906 22:24:44< gfgtdf> mattsc, ok updated it
20180906 22:24:48< mattsc> gfgtdf: yes, in the github comment (I guess that’s not a second example; the second method you post there)
20180906 22:25:21< mattsc> gfgtdf: okay, thanks; that’s how I thought you’d meant it
20180906 22:45:16-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20180906 22:45:45-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20180906 23:02:29-!- wesdiscordbot [~wesdiscor@wesnoth/bot/discord-bridge] has quit [Read error: Connection reset by peer]
20180906 23:02:31-!- wesdiscordbot2 [~wesdiscor@wesnoth/bot/discord-bridge] has joined #wesnoth-dev
20180906 23:02:34-!- mode/#wesnoth-dev [+v wesdiscordbot2] by ChanServ
20180906 23:03:25-!- wesdiscordbot2 is now known as wesdiscordbot
20180906 23:33:12< irker396> wesnoth/wesnoth:1.14 Jyrki Vesterinen 4666ae8c23 [animate_unit]: clear the animation afte AppVeyor: All builds passed
20180906 23:35:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20180906 23:38:02-!- travis-ci [~travis-ci@ec2-54-196-200-213.compute-1.amazonaws.com] has joined #wesnoth-dev
20180906 23:38:03< travis-ci> hryniuk/wesnoth#8 (no-advance-info - e8fa48a : Łukasz Hryniuk): The build passed.
20180906 23:38:03< travis-ci> Build details : https://travis-ci.com/hryniuk/wesnoth/builds/84061280
20180906 23:38:03-!- travis-ci [~travis-ci@ec2-54-196-200-213.compute-1.amazonaws.com] has left #wesnoth-dev []
20180906 23:50:02< irker396> wesnoth: Pentarctagon wesnoth:1.14 44e7b12af67a / CMakeLists.txt SConstruct: Fixes #3518 https://github.com/wesnoth/wesnoth/commit/44e7b12af67af2292f9cc13d91f54a2f8eb35edf
20180906 23:59:31-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
--- Log closed Fri Sep 07 00:00:17 2018