--- Log opened Wed Jul 13 00:00:19 2016
20160713 00:09:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 00:10:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 00:14:28-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20160713 00:27:54-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has quit [Ping timeout: 276 seconds]
20160713 00:40:02-!- prkc [~prkc@46.166.188.226] has joined #wesnoth-dev
20160713 00:40:25-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 00:40:34-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 00:43:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160713 00:46:17-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160713 00:54:32-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160713 01:00:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160713 01:33:19-!- Waste [~Cracker@blk-222-118-4.eastlink.ca] has quit [Remote host closed the connection]
20160713 02:02:57-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160713 02:10:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 02:14:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20160713 03:11:30-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160713 03:13:50-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160713 03:13:51-!- wedge010 is now known as wedge009
20160713 03:33:21-!- JyrkiVesterinen [~JyrkiVest@87-100-150-14.bb.dnainternet.fi] has joined #wesnoth-dev
20160713 03:56:40-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160713 03:57:15-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev
20160713 04:00:23-!- Kwandulin [~Miranda@p200300760F2D81C019764F2B701B622A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160713 04:04:31-!- RatArmy [~RatArmy@133.15.175.65] has quit [Ping timeout: 240 seconds]
20160713 04:07:02-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev
20160713 04:44:15-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 264 seconds]
20160713 05:28:31-!- RatArmy [~RatArmy@133.15.175.65] has quit [Ping timeout: 240 seconds]
20160713 05:29:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 05:33:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160713 05:34:37-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160713 05:36:24-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev
20160713 05:44:03-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160713 05:45:52-!- mjs-de [~mjs-de@x4e31730a.dyn.telefonica.de] has joined #wesnoth-dev
20160713 05:55:23-!- mjs-de [~mjs-de@x4e31730a.dyn.telefonica.de] has quit [Remote host closed the connection]
20160713 06:06:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 06:07:58-!- Kwandulin [~Miranda@p200300760F2D81C019764F2B701B622A.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
20160713 06:11:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 272 seconds]
20160713 06:29:34-!- boucman_work [~boucman@115.202.154.77.rev.sfr.net] has joined #wesnoth-dev
20160713 06:35:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160713 06:40:30-!- irker721 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160713 06:40:30< irker721> wesnoth: Charles Dang wesnoth:master 5649379426ac / data/core/images/projectiles/ (fireball-n-1.png fireball-n-2.png fireball-nw-1.png fireball-nw-2.png): Swapped order of two frames in the fireball animation https://github.com/wesnoth/wesnoth/commit/5649379426ac45cb23611a03ae670180bbf153fa
20160713 06:41:54< vultraz> shouldn't cause problems
20160713 06:41:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 06:46:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160713 06:50:08< vultraz> zookeeper: the campaign PRs look pretty good to me in their current state
20160713 06:59:31-!- boucman_work [~boucman@115.202.154.77.rev.sfr.net] has quit [Ping timeout: 240 seconds]
20160713 07:13:33-!- RatArmy [~RatArmy@133.15.175.65] has quit [Ping timeout: 240 seconds]
20160713 07:21:33< zookeeper> will take some time to determine that
20160713 07:24:06-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev
20160713 07:37:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 07:45:04-!- Kwandulin [~Miranda@p200300760F2D81C06862037611FDCCDA.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160713 07:46:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20160713 07:51:31-!- travis-ci [~travis-ci@ec2-54-92-141-58.compute-1.amazonaws.com] has joined #wesnoth-dev
20160713 07:51:32< travis-ci> wesnoth/wesnoth#9767 (master - 5649379 : Charles Dang): The build has errored.
20160713 07:51:32< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/144372951
20160713 07:51:32-!- travis-ci [~travis-ci@ec2-54-92-141-58.compute-1.amazonaws.com] has left #wesnoth-dev []
20160713 07:53:02-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160713 08:24:09-!- Kwandulin [~Miranda@p200300760F2D81C06862037611FDCCDA.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160713 08:47:32-!- edgrey [~edgrey@178.204.6.196] has joined #wesnoth-dev
20160713 08:51:50-!- woseshaman_ [5f5beb48@gateway/web/freenode/ip.95.91.235.72] has quit [Quit: Page closed]
20160713 08:52:17-!- RatArmy [~RatArmy@133.15.175.65] has quit [Ping timeout: 244 seconds]
20160713 08:59:29-!- Kwandulin [~Miranda@p200300760F2D81C059648A851D0EBF0B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160713 09:05:46-!- boucman_work [~boucman@181.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20160713 09:12:33-!- boucman_work [~boucman@181.195.204.77.rev.sfr.net] has quit [Ping timeout: 240 seconds]
20160713 09:26:27-!- prkc [~prkc@46.166.188.226] has quit [Ping timeout: 246 seconds]
20160713 09:29:31-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has joined #wesnoth-dev
20160713 09:31:38-!- boucman_work [~boucman@110.202.154.77.rev.sfr.net] has joined #wesnoth-dev
20160713 09:42:03-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has joined #wesnoth-dev
20160713 09:47:01-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has quit [Ping timeout: 244 seconds]
20160713 09:47:20-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160713 09:53:43-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has quit [Quit: Leaving]
20160713 09:55:38-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has joined #wesnoth-dev
20160713 10:02:15-!- boucman_work [~boucman@110.202.154.77.rev.sfr.net] has quit [Ping timeout: 264 seconds]
20160713 10:16:43-!- irker721 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160713 10:17:48-!- Appleman1234 [~Appleman1@KD036012035190.au-net.ne.jp] has quit [Read error: Connection reset by peer]
20160713 10:20:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 10:22:11-!- boucman_work [~boucman@181.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20160713 10:24:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160713 10:30:36-!- Kwandulin [~Miranda@p200300760F2D81C059648A851D0EBF0B.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160713 10:31:23-!- Nobun [~nobun@5.170.110.161] has joined #wesnoth-dev
20160713 10:34:47-!- Nobun1 [~nobun@5.170.105.241] has joined #wesnoth-dev
20160713 10:35:07-!- Nobun1 is now known as Nobun_1
20160713 10:35:28-!- Nobun [~nobun@5.170.110.161] has quit [Disconnected by services]
20160713 10:35:35-!- Nobun_1 is now known as Nobun
20160713 10:39:12-!- edgrey [~edgrey@178.204.6.196] has quit [Ping timeout: 244 seconds]
20160713 10:45:24-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160713 10:46:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160713 10:53:59-!- RatArmy [~RatArmy@om126211120067.13.openmobile.ne.jp] has joined #wesnoth-dev
20160713 10:57:45-!- boucman_work [~boucman@181.195.204.77.rev.sfr.net] has quit [Ping timeout: 276 seconds]
20160713 11:02:10-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has quit [Quit: Leaving]
20160713 11:06:48-!- boucman_work [~boucman@181.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20160713 11:14:32-!- Kwandulin [~Miranda@p200300760F2D81C054A07E737E050AAD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160713 11:17:13-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160713 11:33:53-!- edgrey [~edgrey@178.204.47.40] has joined #wesnoth-dev
20160713 11:37:15-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160713 11:39:27-!- Duthlet [~Duthlet@dslb-188-106-029-177.188.106.pools.vodafone-ip.de] has joined #wesnoth-dev
20160713 12:08:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 12:12:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160713 12:20:41-!- gfgtdf [~chatzilla@x4e36a56a.dyn.telefonica.de] has joined #wesnoth-dev
20160713 12:25:21< gfgtdf> vultraz,zookeeper: it seems like in current master the mages attack projektile is missing
20160713 12:25:43< gfgtdf> vultraz, zookeeper when attackign the mages just raise their hands but i see no fireball
20160713 12:33:45-!- Kwandulin [~Miranda@p200300760F2D81C054A07E737E050AAD.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160713 12:34:54-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has joined #wesnoth-dev
20160713 12:39:08< zookeeper> i can't test current master, but if that's true then it's a recent breakage
20160713 12:39:29< zookeeper> since it works just fine on my build that's not even 2 weeks old
20160713 12:58:44< zookeeper> gfgtdf, do any halos work?
20160713 12:59:20< zookeeper> such as the white mage lightbeam animation
20160713 13:04:31-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Ping timeout: 240 seconds]
20160713 13:04:56-!- RatArmy [~RatArmy@om126211120067.13.openmobile.ne.jp] has quit [Ping timeout: 258 seconds]
20160713 13:19:59-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has joined #wesnoth-dev
20160713 13:22:41-!- ancestral [~ancestral@75-168-183-92.mpls.qwest.net] has joined #wesnoth-dev
20160713 13:40:48< gfgtdf> zookeeper: white mages attack doesnt work eigher
20160713 13:41:12< zookeeper> then i'd first suspect that recent halo fix
20160713 13:41:32-!- edgrey [~edgrey@178.204.47.40] has quit [Quit: Konversation terminated!]
20160713 13:41:39< zookeeper> dunno if anything else has been done that could conceivably affect halos
20160713 13:42:15-!- edgrey [~edgrey@178.204.47.40] has joined #wesnoth-dev
20160713 13:42:31-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 250 seconds]
20160713 13:42:51< gfgtdf> zookeeper: wait it seemsed to just be a be a wrong value in my game prefecnes,
20160713 13:43:00< zookeeper> ...whoops
20160713 13:43:09< gfgtdf> zookeeper: somhow the attack missels of mages and the one of bowmans fall under difference categories
20160713 13:43:33< zookeeper> yes, most projectiles aren't done as halos
20160713 13:43:56< zookeeper> but a lot of the magic effects, but not all, are
20160713 13:44:37-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160713 13:47:28< gfgtdf> zookeeper: i don't really know anything about how animations are implemented, but i think that its quite unexpected that that prefecne option disables magic attack missels but not bowman attakc missles.
20160713 13:47:46< zookeeper> sure, it is
20160713 13:48:08< zookeeper> i believe at some point the option was planned to be removed, because it just doesn't make sense as an option
20160713 13:48:31< zookeeper> the only reason not to remove it would be that if someone really needs it for performance reasons
20160713 13:50:18-!- edgrey [~edgrey@178.204.47.40] has quit [Quit: Konversation terminated!]
20160713 13:50:44-!- edgrey [~edgrey@178.204.47.40] has joined #wesnoth-dev
20160713 13:51:35-!- edgrey [~edgrey@178.204.47.40] has quit [Remote host closed the connection]
20160713 13:51:46-!- ancestral [~ancestral@75-168-183-92.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160713 13:52:02-!- edgrey [~edgrey@178.204.47.40] has joined #wesnoth-dev
20160713 13:53:34-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160713 13:54:04< Nobun> zookeeper: I'm not an expert about performances, but I think that probably that option would not have so huge impact on performances, as long it has impact only on one or two units at the same time at max
20160713 13:55:02< Nobun> about performances, it has more impact the unit animations (example: standing animation while unit does not move) or terrain animation, wich have impact on all the battlefield
20160713 13:55:50< zookeeper> as far as combat animations go it's of course limited to two at a time, but then there's also the rare MoL/shyde halos and such
20160713 13:57:14< zookeeper> personally i can't really see them having a noticeable performance impact on any system that can comfortably run the game in the first place
20160713 14:00:42< zookeeper> it's a kind of a last resort option: you should always toggle off standing and terrain animations first, because those have a much greater impact
20160713 14:00:51-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has quit [Ping timeout: 246 seconds]
20160713 14:07:25-!- boucman_work [~boucman@181.195.204.77.rev.sfr.net] has quit [Ping timeout: 244 seconds]
20160713 14:20:43-!- boucman_work [~boucman@181.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20160713 14:29:44-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160713 14:49:35-!- boucman_work [~boucman@181.195.204.77.rev.sfr.net] has quit [Quit: Leaving.]
20160713 14:50:22-!- gfgtdf [~chatzilla@x4e36a56a.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160713 15:06:46-!- JyrkiVesterinen [~JyrkiVest@87-100-150-14.bb.dnainternet.fi] has quit [Quit: .]
20160713 15:11:31-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160713 15:13:54-!- Appleman1234 [~Appleman1@KD036012035190.au-net.ne.jp] has joined #wesnoth-dev
20160713 15:14:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160713 15:14:31-!- wedge010 is now known as wedge009
20160713 15:14:48-!- Kwandulin [~Miranda@p200300760F2D81C019D38E3B89BC0E2E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160713 15:34:36-!- atarocch [~atarocch@151.64.77.13] has joined #wesnoth-dev
20160713 15:43:03-!- midzer_ [~quassel@p57B4551A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160713 15:44:43-!- midzer [~quassel@p5B2964B5.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20160713 15:52:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 15:52:24-!- boucman_work [~boucman@2a02-8428-034f-f800-59f7-e933-f370-42a4.rev.sfr.net] has joined #wesnoth-dev
20160713 15:53:29-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160713 15:53:30-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160713 15:56:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 272 seconds]
20160713 15:58:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 15:59:43-!- Nobun [~nobun@5.170.105.241] has quit [Quit: Salve a tutti]
20160713 16:02:15-!- boucman_work [~boucman@2a02-8428-034f-f800-59f7-e933-f370-42a4.rev.sfr.net] has quit [Ping timeout: 264 seconds]
20160713 16:03:46-!- JyrkiVesterinen [~JyrkiVest@87-92-47-219.bb.dnainternet.fi] has joined #wesnoth-dev
20160713 16:08:31-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160713 16:12:49-!- boucman_work [~boucman@2a02-8428-034f-f800-59f7-e933-f370-42a4.rev.sfr.net] has joined #wesnoth-dev
20160713 16:15:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 16:18:04-!- prkc [~prkc@46.166.138.139] has joined #wesnoth-dev
20160713 16:24:02-!- Kwandulin [~Miranda@p200300760F2D81C019D38E3B89BC0E2E.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160713 16:24:27-!- boucman_work [~boucman@2a02-8428-034f-f800-59f7-e933-f370-42a4.rev.sfr.net] has quit [Ping timeout: 264 seconds]
20160713 16:25:31-!- boucman_work [~boucman@221.86.207.77.rev.sfr.net] has joined #wesnoth-dev
20160713 16:28:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 16:35:30-!- boucman_work [~boucman@221.86.207.77.rev.sfr.net] has quit [Remote host closed the connection]
20160713 16:40:59-!- boucman_work [~boucman@2a02-8428-034f-f800-8e4d-3298-0536-3a48.rev.sfr.net] has joined #wesnoth-dev
20160713 16:44:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 16:48:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 17:11:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 17:13:03-!- boucman_work [~boucman@2a02-8428-034f-f800-8e4d-3298-0536-3a48.rev.sfr.net] has quit [Ping timeout: 264 seconds]
20160713 17:13:28-!- boucman_work [~boucman@221.86.207.77.rev.sfr.net] has joined #wesnoth-dev
20160713 17:15:27-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160713 17:27:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 17:29:59-!- edgrey [~edgrey@178.204.47.40] has quit [Quit: Konversation terminated!]
20160713 17:32:14-!- edgrey [~edgrey@178.204.47.40] has joined #wesnoth-dev
20160713 17:57:43-!- iwaim [~iwaim@rasteenie.alib.jp] has quit [Ping timeout: 252 seconds]
20160713 18:01:48< JyrkiVesterinen> Significant milestone on the Monte Carlo damage prediction mode: I have a working basic implementation. :)
20160713 18:01:50< JyrkiVesterinen> https://github.com/jyrkive/wesnoth/commit/49d0831d0ae5e394a792b87ae92f9019b9439623
20160713 18:01:53-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160713 18:02:12< JyrkiVesterinen> There are still a few things to do, but I think I'll create a PR next week at the latest.
20160713 18:02:48-!- iwaim [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20160713 18:18:06-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160713 18:22:07-!- boucman_work [~boucman@221.86.207.77.rev.sfr.net] has quit [Read error: Connection reset by peer]
20160713 18:35:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 18:37:40-!- gfgtdf [~chatzilla@x4e36a56a.dyn.telefonica.de] has joined #wesnoth-dev
20160713 18:38:19< gfgtdf> i'm getting some "invalid stoi" erro in master
20160713 18:39:11-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160713 18:40:39-!- iwaim [~iwaim@rasteenie.alib.jp] has quit [Ping timeout: 264 seconds]
20160713 18:40:54< celmin> Where?
20160713 18:41:23< gfgtdf> in  TRoW scwnario 4 swamps
20160713 18:41:40< gfgtdf> scenario*
20160713 18:41:44< gfgtdf> at tun 3
20160713 18:41:52< gfgtdf> during at uturn i think but im not sure
20160713 18:43:28< zookeeper> probably either from AI, or from the moveto event
20160713 18:45:06< gfgtdf> zookeeper: lua stack say something about event, but there are no moveto event that trigger on ai turn so i think it migth be a new turn event
20160713 18:45:22-!- iwaim [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20160713 18:45:36< zookeeper> oh right, there's a nested one
20160713 18:46:48< zookeeper> well, shouldn't be a problem in the scenario itself seeing how it hasn't received any changes that might cause it
20160713 18:47:34< gfgtdf> zookeeper: that doesn't really make it better.
20160713 18:48:17< gfgtdf> vultraz: i think you did the stoi commit ?
20160713 18:48:23< zookeeper> of course it doesn't, but i'm just saying that in case someone's otherwise going to edit the scenario to make it go away
20160713 18:52:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 19:02:12< gfgtdf> zookeeper: ok i thinkth ebug in teh scenario is that https://github.com/wesnoth/wesnoth/blob/1cc3711996923636e5e979b00dbd9f7e5dbd24d8/data/campaigns/The_Rise_Of_Wesnoth/scenarios/04a_The_Swamp_of_Esten.cfg#L269 also stores unit on the recall list, and the follwing code cannot hande that
20160713 19:04:17< zookeeper> right, sounds likely. i'd suspect the [set_variable] changes
20160713 19:04:55< zookeeper> just a hunch, might be something else
20160713 19:07:23< gfgtdf> zookeeper: i wonder why x="recall" is not enough to fitler for recall units? for some reason i have to type x="recall" y=recall in the filter
20160713 19:07:55< zookeeper> the [store_unit] filter should of course have a x,y=1-999,1-999 (or whatever) to exclude recall list units, but might as well fix the cause of the actual error first...
20160713 19:08:07< zookeeper> i'm not sure, sounds like a bug
20160713 19:10:25< celmin> I dunno, might be intentional.
20160713 19:10:31< celmin> Not that that's an argument against changing it.
20160713 19:10:41< celmin> In WML you normally write x,y=recall,recall
20160713 19:11:19< zookeeper> yeah that's the way i'd write it too for clarity's sake, but... if x,y=recall,recall matches, then so should just x=recall
20160713 19:11:27< zookeeper> just like if you had coordinates there
20160713 19:11:44-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
20160713 19:12:31< zookeeper> gfgtdf, anyway, it doesn't look like [set_variable] is likely to blame (as far as i can tell), so i think that only leaves [store_locations] as a candidate
20160713 19:12:54< zookeeper> (or the SLF code in general)
20160713 19:12:55< celmin> If it's actually checking for the string "recall", then changing this is probably as simple as changing a && to || somewhere.
20160713 19:14:11< gfgtdf> zookeeper: y i also think its store_location /location fitelers in genreral
20160713 19:16:10< gfgtdf> im quite sure its casues by this patch: https://github.com/wesnoth/wesnoth/commit/1d0e4fff417fb5ddd8ceecf0948a9fcc6e65721a
20160713 19:16:15< zookeeper> i hope vultraz doesn't mind if i suspect him, but i'd check if it's 1d0e4fff41..... yes, that :P
20160713 19:17:04< gfgtdf> we shodul fix this before release, maybe change all those to lexicakl_cast_default(str, 0) which does the same as teh previousl code but is a littel cleaner
20160713 19:17:30< celmin> That sounds like a bad idea.
20160713 19:17:31< gfgtdf> even if that defautl value doesnt really make sense in most cases
20160713 19:17:33< zookeeper> i don't know the code but the diff makes it look plausible that it no longer copes with empty x,y
20160713 19:17:50< celmin> You should catch the exception and print an error message.
20160713 19:18:04< celmin> Ah, yes, if they're empty though it should not be an error.
20160713 19:18:17< zookeeper> passing an empty x,y shouldn't result in an error
20160713 19:18:19< celmin> I didn't look closely.
20160713 19:18:21< zookeeper> it should just do nothing
20160713 19:18:44< celmin> But yeah, empty x,y just means "any location"
20160713 19:18:49< gfgtdf> celmin: well yes feel free to do that.
20160713 19:19:17< celmin> I can do it, but you could do it just as easily if you've identified the cause.
20160713 19:20:03< gfgtdf> I just looked for the bug in the wml cod  not in the c++ code.
20160713 19:20:31< celmin> If it's standard location filters, it's easy to find in the C++ code.
20160713 19:21:27< celmin> Actually, it's probably a good idea to review the entire 1d0e4fff commit and change every instance to avoid exceptions.
20160713 19:21:52< gfgtdf> yes, obviously.
20160713 19:22:06< celmin> Maybe vultraz will be willing to do it since it's his fault.
20160713 19:28:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160713 19:31:07-!- mjs-de [~mjs-de@x4db50acd.dyn.telefonica.de] has joined #wesnoth-dev
20160713 19:32:03< vultraz> hm?
20160713 19:32:09< vultraz> i see I am being blamed for something
20160713 19:32:11 * vultraz reads log
20160713 19:32:30< celmin> For changing to stoi without understanding the consequences.
20160713 19:35:30< vultraz> alright, fair enough
20160713 19:35:36< vultraz> how should I handle this
20160713 19:36:54< celmin> Well, as I recall, the consequences are that stoi can throw an exception, so any time you're applying it to input from a config, you need to take that into consideration and handle the exception.
20160713 19:37:20< celmin> (Or input from Lua, of course.)
20160713 19:39:11< vultraz> so I need to try/catch every single case
20160713 19:40:14< celmin> There might be some places where a single try-catch will cover multiple ones, and there could theoretically be occasional places where you know that the input will be valid and don't need to worry about catching it, but yeah, that's the general idea.
20160713 19:41:28< vultraz> blagh
20160713 19:41:37< vultraz> this will take all day
20160713 19:42:21< celmin> That wouldn't surprise me.
20160713 19:42:37< celmin> Sometimes an empty string will need to be considered valid, BTW, as we mentioned earlier.
20160713 19:43:46< celmin> …thinking about it, would x,y in location filters really trigger stoi?
20160713 19:44:11< celmin> Does the config class call stoi?
20160713 19:44:29< celmin> I wouldn't expect it to since it's implemented as a variant.
20160713 19:45:55< vultraz> doesn't seem to be the case, no
20160713 19:47:17< celmin> Well, whatever. If all the stoi cases are covered, than the cause of gfgtdf's bug will surely be fixed...
20160713 19:47:32< vultraz> I dunno when I can be sure the value is always going to be valid..
20160713 19:48:42< celmin> Only if it's from a trusted source.
20160713 19:49:10< celmin> Which is probably unlikely.
20160713 19:49:27< celmin> WML values and Lua parameters are definitely untrusted sources.
20160713 19:50:10< vultraz> and what exception should be caught? 
20160713 19:51:05< celmin> I dunno, maybe bad_cast_exception? Google stoi and you'll find out.
20160713 19:51:24-!- prkc [~prkc@46.166.138.139] has quit [Ping timeout: 276 seconds]
20160713 19:51:49< vultraz> std::invalid_argument
20160713 19:52:11< vultraz> or... std::out_of_range
20160713 19:52:32< celmin> invalid_argument is the more important one, I think.
20160713 19:52:38< vultraz> ok
20160713 19:53:03< celmin> I guess out_of_range is if it tries to convert a very large number? Would be good to handle that as well, but it's more of an edge case.
20160713 19:53:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 19:54:17< celmin> People won't be inputting very large numbers unless they're trying to be actively malicious, and in that case the program would just crash anyway, so it's not like it's unsafe.
20160713 19:54:41< vultraz> blagh, and I also have to decide what to do if it catches an error...
20160713 19:55:03< celmin> A good fallback is to print an error message, either to lg::wml_error or to a logging stream.
20160713 19:55:42< celmin> And depending on context, you could either substitute a default or behave as if it were nil.
20160713 19:55:53< celmin> (Which in the WML case means behaving as if the key were absent.
20160713 19:55:54< celmin> )
20160713 19:58:22< vultraz> if I finish this I'll probably PR it so you can check it
20160713 19:58:33< celmin> That's fine.
20160713 20:03:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160713 20:05:11-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has joined #wesnoth-dev
20160713 20:11:23-!- RatArmy [~RatArmy@om126211120067.13.openmobile.ne.jp] has joined #wesnoth-dev
20160713 20:16:21< vultraz> ok, this *might* not take all day
20160713 20:20:00-!- JyrkiVesterinen [~JyrkiVest@87-92-47-219.bb.dnainternet.fi] has quit [Quit: .]
20160713 20:20:26-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has quit [Ping timeout: 272 seconds]
20160713 20:28:59-!- RatArmy [~RatArmy@om126211120067.13.openmobile.ne.jp] has quit [Quit: Konversation terminated!]
20160713 20:30:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 20:31:43< vultraz> ok, this is probably where the bug came from
20160713 20:33:00-!- prkc [~prkc@46.166.138.132] has joined #wesnoth-dev
20160713 20:38:42-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160713 20:38:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds]
20160713 20:45:54< iceiceice> i opened a support issue on travis-ci
20160713 20:45:55< iceiceice> https://github.com/travis-ci/travis-ci/issues/6300
20160713 20:46:12< iceiceice> y'all are welcome to "heart" it or whatever
20160713 21:02:31-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has quit [Quit: Leaving]
20160713 21:16:31-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has joined #wesnoth-dev
20160713 21:25:03-!- stikonas_ is now known as stikonas
20160713 21:29:39-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160713 21:33:52-!- prkc [~prkc@46.166.138.132] has quit [Ping timeout: 252 seconds]
20160713 21:36:46< vultraz> celticminstrel: how should I handle this? https://github.com/wesnoth/wesnoth/blob/1d0e4fff417fb5ddd8ceecf0948a9fcc6e65721a/src/serialization/string_utils.cpp#L207
20160713 21:37:06< vultraz> try around the loop?
20160713 21:43:07-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 21:43:54-!- Appleman1234 [~Appleman1@KD036012035190.au-net.ne.jp] has quit [Ping timeout: 246 seconds]
20160713 21:45:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160713 21:49:38-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has joined #wesnoth-dev
20160713 21:52:45< celmin> No.
20160713 21:53:24< celmin> Hmm.
20160713 21:53:37< celmin> So this is in square_parenthetical_split.
20160713 21:55:23< celmin> Well, I suppose try-catch around the loop could work, but I'm wondering if this might be a good place to defer the exception handling to the caller.
20160713 21:55:31< vultraz> celmin / celticminstrel: this is what I have so far, baring stuff in the above file and some cases I think will always be valid (like the forum_user_handler) case: https://github.com/Vultraz/wesnoth/commit/95e14636f145319aba1a9baf6f5bd6d3badf8a1f
20160713 21:55:39< celmin> In other words, ignore the exception here, but surround calls to that function with try-catch.
20160713 21:55:42< celmin> Not sure though.
20160713 21:56:01< celmin> Can you point out the cases you think are always valid as well?
20160713 21:57:03< vultraz> everything in server/forum_user_handler.cpp and uh.... the TEST_MAPGEN program in generators/map_generator.cpp
20160713 21:57:05< vultraz> think that;s it
20160713 21:58:52-!- edgrey [~edgrey@178.204.47.40] has quit [Quit: Konversation terminated!]
20160713 22:03:50< celmin> The commit you linked appears to have some random indentation changes?
20160713 22:04:14< vultraz> there's one spot where the indent got screwed up, I'll fix
20160713 22:06:06< vultraz> two spots where I also changed bare iterators to range-for.
20160713 22:06:38-!- mjs-de [~mjs-de@x4db50acd.dyn.telefonica.de] has quit [Remote host closed the connection]
20160713 22:08:07< vultraz> celmin: let me know if I should add error messages in places where I didn't include any
20160713 22:08:23< celmin> Hmm. The forum_user_handler cases are taken from a database, so while it may not be totally trustworthy I suppose it's not too bad...
20160713 22:08:48< celmin> I'll look over your commit in a bit, skipping the reindented part (unless you link the fixed version).
20160713 22:15:54< vultraz> celmin: https://github.com/Vultraz/wesnoth/commit/d68aba5bf9efb75a232b591b56298baa273d7b82
20160713 22:18:34-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 22:19:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 22:20:08-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has quit [Quit: Leaving]
20160713 22:27:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 22:29:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20160713 22:30:26-!- Duthlet [~Duthlet@dslb-188-106-029-177.188.106.pools.vodafone-ip.de] has quit [Quit: leaving]
20160713 22:31:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160713 22:40:37-!- Appleman1234 [~Appleman1@KD036012037023.au-net.ne.jp] has joined #wesnoth-dev
20160713 22:45:42 * vultraz curses
20160713 22:45:56< vultraz> seeing a crash, dunno if it's related to my changes
20160713 22:47:55< vultraz> celticminstrel: could you go into the editor, open a menu and then close it, and see if wesnoth crashes
20160713 22:48:10< vultraz> (without my changes, of course)
20160713 22:49:27< Aginor> vultraz: git stash, rebuild, try again, git stash apply if good
20160713 22:49:52< Aginor> if it's in events.cpp it's me ;)
20160713 22:50:18< vultraz> I think it might be, but let me check
20160713 22:51:23< vultraz> for some reason my commit causes a large rebuild without touching any header files..
20160713 22:52:01< vultraz> maybe it's the log include?
20160713 22:52:12< vultraz> oh well, I'll leave that to celmin
20160713 22:52:45< vultraz> i mean to see if there's something wrong with the log changes in my commit
20160713 22:52:55 * vultraz waits for his 20 minute build to finish
20160713 22:53:31< Aginor> vultraz: change the instance of std::vector to std::list in events.cpp for handlers
20160713 22:55:21-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 276 seconds]
20160713 22:55:47< Aginor> the calls to .size() on those lists should be removed too, looking at the loops iterating over them I don't see why they would ever need that call in the first place
20160713 22:56:17< vultraz> i also observed weird behavior with button overlays in-game (not editor) after closing a menu
20160713 22:56:23< vultraz> some of them disappeared until you select a unit
20160713 22:56:42< vultraz> will test again without my change, and then with your proposed change
20160713 22:57:35< Aginor> if the crash is in events.cpp it's because the vector was modified while being iterated over, invalidating the iterator
20160713 22:57:45< Aginor> but the modification happens in another context
20160713 22:57:47< vultraz> i thought you had fixed that
20160713 22:58:04< Aginor> no, I fixed it for a specific context
20160713 22:58:19< Aginor> but the general fix is to change the datastructure
20160713 22:58:26< vultraz> ah ah
20160713 23:01:30< vultraz> god, I need a better laptop
20160713 23:01:55< vultraz> something with an i7 and 16 GBs of ram
20160713 23:03:25< Aginor> 16 is so last decade
20160713 23:03:30< Aginor> 32 is the new 16
20160713 23:03:44< vultraz> I thought 16 was the new 8 :P
20160713 23:06:44< vultraz> zzzzzzz
20160713 23:08:19< Aginor> yeah
20160713 23:10:31< Aginor> I've started to think about upgrading my desktop a bit more
20160713 23:10:32< Aginor> http://cpu.userbenchmark.com/Compare/Intel-Core-i7-6700K-vs-AMD-FX-8120/3502vsm173
20160713 23:10:46< Aginor> that's close to a 100% average performance gain :D
20160713 23:11:42< Aginor> both use some flavour of hyper threading to achieve 8 "cores"
20160713 23:11:49< Aginor> the difference is that intel is more honest
20160713 23:13:48< vultraz> the intel one looks better
20160713 23:15:33< vultraz> 24 minutes for build :|
20160713 23:16:17< vultraz> ok
20160713 23:16:22< vultraz> both bugs happen without my changes
20160713 23:16:27< vultraz> will try your proposed fix..
20160713 23:18:37< celmin> …what're you leaving to me now, vultraz?
20160713 23:18:58< celmin> (Your second link still seems to have the indentation change, so skipping over that.)
20160713 23:19:12< vultraz> celmin: for some reason, my commit results in almost everything  eing rebuilt, even though I don;t touch any header 
20160713 23:19:18< celmin> (Oh, it might not be as bad as before though, actually.)
20160713 23:19:25< vultraz> celmin: what indent change?
20160713 23:19:49< celmin> Ohhh, it's not actually an indent change, it's a for-range change.
20160713 23:20:06< celmin> Doesn't the stoi stuff touch a lot of files?
20160713 23:20:43< vultraz> no headers
20160713 23:21:06< celmin> Why did you remove the else-clause at line 321 of display.cpp?
20160713 23:21:52< vultraz> I assigned those as initial values
20160713 23:22:03< celmin> Ah, I see it now.
20160713 23:22:05< celmin> Makes sense.
20160713 23:22:27< celmin> What's the type of itor...
20160713 23:22:36< vultraz> the try block warned that those values could be used uninitialized, so that made sense
20160713 23:23:02< vultraz> Aginor: which... cases of vector do I have to change to list?
20160713 23:23:30< celmin> Well, time would've been uninitialized if an exception was thrown, though str would still be initialized...
20160713 23:24:13 * vultraz guesses 'all of them'
20160713 23:24:32< celmin> So this way you have a useless copy. Eh, I guess it's okay.
20160713 23:25:33< celmin> vultraz: In formula.cpp I think you don't need to worry about catching it because the input has already been previously verified to be a number.
20160713 23:25:37< vultraz> btw, what did the 'for(;' mean?
20160713 23:25:55< celmin> Wait, there's two of them, hmm...
20160713 23:26:01< Aginor> vultraz: event_handlers in the context(?) type
20160713 23:26:09< celmin> vultraz: To answer that I need to explain how for works.
20160713 23:26:23< celmin> for(init_statement; condition; final_statement)
20160713 23:26:30< Aginor> I'm at work so I won't bring up the code to
20160713 23:26:40< Aginor> which makes it hard for me to look
20160713 23:26:49< celmin> is equivalent to {init_statement; while(condition) {…; final_statement;}}
20160713 23:26:51< Aginor> search for event_handlers and you'll find them
20160713 23:27:06< celmin> So, "for(;" means that init_statement is an empty statement.
20160713 23:27:23< celmin> Any of the parts of a for-loop may be left empty.
20160713 23:27:26< vultraz> I see
20160713 23:28:58< celmin> Okay, yeah, I don't think you need to catch the exception in formula.cpp in either instance.
20160713 23:29:35< celmin> (Unrelatedly, I just spotted something annoying on line 1131. It's subtracting 48 when it would make more sense to subtract '0'. They're equivalent, but the latter makes the intent more clear.)
20160713 23:30:35< vultraz> ... how is that the same
20160713 23:30:37< celmin> vultraz: Should I post github comments instead of commenting in here?
20160713 23:30:42< vultraz> please
20160713 23:30:44< celmin> It's the same because '0' == 48, obviously.
20160713 23:31:33 * vultraz blinks
20160713 23:31:40-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev
20160713 23:31:46< vultraz> you lost me
20160713 23:32:09< celmin> Characters in C are just integers, so it shouldn't be surprising that a character constant is equal to its ASCII value.
20160713 23:32:27< celmin> Don't forget that single and double quotes mean different things in C, unlike in Lua.
20160713 23:33:12< vultraz> are you saying the ascii value of '0' is 48?
20160713 23:33:45< celmin> Yes.
20160713 23:34:13< vultraz> but not "0"
20160713 23:34:54< celmin> Well, '0' is of type char while "0" is of type char* equivalent to {'0', '\0'}.
20160713 23:35:21< celmin> So, there's still a 48 involved with "0", but "0" != 48.
20160713 23:35:39< celmin> ^const char*
20160713 23:35:45< vultraz> I .. see
20160713 23:36:06< vultraz> I don't understand what it's doing with that 48 in any case, though
20160713 23:37:25< Aginor> are we having our own function to convert from strings to numbers?
20160713 23:38:37< celmin> If you mean "what is it doing on line 1131 of formula.cpp" the answer is "converting an ASCII digit to its numeric value".
20160713 23:39:08< celmin> Just as '0' is 48, the subsequent digits follow from that, for example '1' is 49 and '9' is 57.
20160713 23:39:27< vultraz> I...see
20160713 23:39:37< celmin> So you can get the numeric value by subtracting 48 (or, equivalently, by subtracting '0')
20160713 23:39:44< vultraz> Aginor: I can't get this to build, you'll have to look at it yourself later
20160713 23:41:25< Aginor> vultraz: ok. you probably just need to change the types everywhere :D
20160713 23:41:48< Aginor> maybe even introduce a typedef or two to make it nice in the future
20160713 23:50:10< vultraz> problem is this |error: no match for 'operator+' (operand types are 'std::__cxx11::list<events::sdl_handler*>::iterator {aka std::_List_iterator<events::sdl_handler*>}' and 'size_t {aka unsigned int}')|
20160713 23:51:33< celmin> Oh, looks like I've finished going over your commit.
20160713 23:52:15< celmin> vultraz: Yeah, you want to refactor so that addition is not required. Where is this error occurring?
20160713 23:53:23< vultraz> handlers.erase(handlers.begin()+handler);
20160713 23:53:31< vultraz> events.cpp:57
20160713 23:53:42< celmin> Hmm.
20160713 23:54:03< celmin> Is events.cpp in src/ toplevel?
20160713 23:54:07< vultraz> yes
20160713 23:55:34< celmin> How often is delete_handler_index called?
20160713 23:55:54< celmin> That's the wrong question. I mean from how many places.
20160713 23:56:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160713 23:56:18< vultraz> 3
20160713 23:56:49< celmin> Okay, so it should be fine to rename it to delete_handler and make it take an iterator as argument instead of an index. Then you can just call handlers.erase(handler).
20160713 23:57:01< celmin> You'll also need to change focused_handler to be an iterator instead of an index.
20160713 23:57:24 * vultraz groans
20160713 23:57:31< celmin> You can use end() for -1, probably.
20160713 23:57:56< celmin> Were you hoping you wouldn't have to touch the header?
20160713 23:58:11< vultraz> i already touched the header
20160713 23:58:16< celmin> Ah okay.
20160713 23:58:27< vultraz> I just can't remember how you pass an iterator as an argument
20160713 23:58:31< celmin> You can simulate addition with std::advance, but that's inefficient.
20160713 23:58:36< celmin> Uh, the same way you pass anything else?
20160713 23:59:20< vultraz> no, what's the type
20160713 23:59:30< celmin> Oh, I just noticed something interesting...
20160713 23:59:54< celmin> (The type in this case is std::list<whatever>::iterator, or maybe const_iterator.)
--- Log closed Thu Jul 14 00:00:13 2016