--- Log opened Mon Dec 05 00:00:08 2016 20161205 00:17:44-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has joined #wesnoth-dev 20161205 00:22:41-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 265 seconds] 20161205 00:25:23-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has quit [Remote host closed the connection] 20161205 00:34:17-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has joined #wesnoth-dev 20161205 00:38:47-!- louis94 [~~louis94@91.178.241.57] has quit [Ping timeout: 260 seconds] 20161205 00:39:56-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 00:39:56< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Failed 20161205 00:39:56< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-14 20161205 00:39:56< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 00:40:00-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 01:03:33-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 01:03:33< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Succeeded 20161205 01:03:33< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-14 20161205 01:03:33< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 01:03:37-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 01:06:40-!- travis-ci [~travis-ci@ec2-54-147-34-26.compute-1.amazonaws.com] has joined #wesnoth-dev 20161205 01:06:41< travis-ci> gfgtdf/wesnoth-old#710 (master - 70d15b7 : gfgtdf): The build was fixed. 20161205 01:06:41< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/181216495 20161205 01:06:41-!- travis-ci [~travis-ci@ec2-54-147-34-26.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161205 01:06:57-!- Appleman1234_ [~Appleman1@KD106161200237.au-net.ne.jp] has joined #wesnoth-dev 20161205 01:10:03-!- Appleman1234 [~Appleman1@KD106161214057.au-net.ne.jp] has quit [Ping timeout: 265 seconds] 20161205 01:11:13-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev 20161205 01:11:34-!- Appleman1234_ is now known as Appleman1234 20161205 01:21:50-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Read error: Connection reset by peer] 20161205 01:22:05-!- RatArmy_ [~ratarmy@om126229084093.12.openmobile.ne.jp] has joined #wesnoth-dev 20161205 01:22:07< vultraz> celticminstrel: on second thought, I'm not sure enable_shared_from_this is needed here at all...since get_ptr isn't used :/ 20161205 01:22:22< vultraz> rereading the cppreference docs seems to indicate that's the whole point 20161205 01:22:23-!- RatArmy_ [~ratarmy@om126229084093.12.openmobile.ne.jp] has quit [Read error: Connection reset by peer] 20161205 01:22:53< vultraz> but since you told me to use return std::make_shared(atk);, get_ptr is never called. 20161205 01:23:03-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 01:27:08-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has quit [Remote host closed the connection] 20161205 01:27:18< vultraz> unrelated: converting the attack predictions dialog to GUI2 is more work than i expected 20161205 01:27:22< vultraz> even for just the text part :| 20161205 01:33:12< celticminstrel> vultraz: There are likely places where get_ptr should be used if you were going to switch to enable_shared_from_this. 20161205 01:33:25< celticminstrel> You'd have to examine every single attack_ptr variable to see if you need to use get_ptr. 20161205 01:33:53< vultraz> oh dear 20161205 01:34:19-!- gfgtdf [~chatzilla@x4e363921.dyn.telefonica.de] has quit [Read error: Connection reset by peer] 20161205 01:35:29< celticminstrel> I'm not entirely sure whether there are such places, but it's likely; and for units, even likelier. 20161205 01:35:46-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 01:35:46< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Succeeded 20161205 01:35:46< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-15 20161205 01:35:46< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 01:35:50-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 01:36:16< vultraz> good god AV is late 20161205 01:43:17< vultraz> ugh, this code 20161205 01:44:27< vultraz> oh, fun, snprintf 20161205 01:47:15< vultraz> how would this be converted to c++? http://pastebin.com/UM79yU8h 20161205 01:47:45< celticminstrel> snprintf is fairly easy to convert to C++ streams. 20161205 01:48:57< celticminstrel> Okay, so for the 4 or 3 you'd use std::setw. 20161205 01:49:03< celticminstrel> (Which is in 20161205 01:49:13< celticminstrel> And the .1 would be std::setprecision(1) IIRC. 20161205 01:49:29< celticminstrel> %% just means to output a percent sign, so you can dedouble it. 20161205 01:50:06< celticminstrel> Oh wow, that function gives the illusion of being safe when it really isn't. 20161205 01:50:51< celticminstrel> Someone looking at the declaration might think, "Oh, it only takes a 10-character array and doesn't write more than 8 characters, of course it's safe". 20161205 01:50:56< celticminstrel> BUT 20161205 01:51:14< celticminstrel> In function arguments, "T arg[n]" is functionally identical to "T* arg". 20161205 01:51:30< celticminstrel> So it's really taking a pointer to char which may point to an area of any size imaginable. 20161205 01:52:03< celticminstrel> A C++ version would just take the probability and return the result, though. So if you're converting it to streams you can just drop the array argument. 20161205 01:55:57< vultraz> how much w? 20161205 01:56:02< vultraz> for setw 20161205 01:56:32< vultraz> 4 and 3? 20161205 01:57:56< vultraz> celticminstrel: http://pastebin.com/SZb5ynip 20161205 01:58:08< celticminstrel> Yesy. 20161205 01:58:14< celticminstrel> ^-y 20161205 01:58:25< celticminstrel> That's correct. 20161205 01:58:40< celticminstrel> To get the exact same effect you'd have a space before the %, but I don't personally feel that that's very important. 20161205 01:59:19< celticminstrel> You could probably factor most of that out of the if, and only do setw in the if. 20161205 01:59:36< celticminstrel> (And the one case really doesn't even need the stream.) 20161205 01:59:47< celticminstrel> Up to you whether that's worth it. 20161205 02:00:04-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 02:00:04< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Succeeded 20161205 02:00:04< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-15 20161205 02:00:04< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 02:00:09-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 02:21:14-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has joined #wesnoth-dev 20161205 02:23:01-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20161205 02:35:05-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has quit [Remote host closed the connection] 20161205 02:54:50-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev 20161205 03:04:46-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Read error: Connection reset by peer] 20161205 03:05:35-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 03:07:57-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Read error: Connection reset by peer] 20161205 03:08:28-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 03:14:45-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Ping timeout: 248 seconds] 20161205 03:16:11-!- RatArmy_ [~ratarmy@om126212253245.14.openmobile.ne.jp] has joined #wesnoth-dev 20161205 03:18:30-!- RatArmy_ [~ratarmy@om126212253245.14.openmobile.ne.jp] has quit [Read error: Connection reset by peer] 20161205 03:31:45< vultraz> why 20161205 03:31:47< vultraz> is unit_ability_list 20161205 03:31:49< vultraz> its own class 20161205 03:31:51< vultraz> :| 20161205 03:34:57< celticminstrel> More importantly, what on earth is unit_ability_list? 20161205 03:35:17< vultraz> a class that encapsulates a vector of unit_ability 20161205 03:35:19< celticminstrel> I don't think it's what the name implies. 20161205 03:35:38< celticminstrel> Like, where is it used and for what. 20161205 03:35:41< vultraz> and then implements wrappers around the vector getters 20161205 03:35:58< vultraz> the only unique functions are highest() and lowest() 20161205 03:36:23< vultraz> which return std::pair 20161205 03:36:46< celticminstrel> Which file was it in again. 20161205 03:37:12< celticminstrel> Never mind, found it. 20161205 03:37:13< vultraz> the class is in unit.hpp 20161205 03:37:20< vultraz> the impl is in abilities.cpp 20161205 03:39:09< vultraz> why in hell do you need a wrapper class for THESE functions 20161205 03:39:43< vultraz> they can be global functions that take vectors of unit_ability 20161205 03:39:46< celticminstrel> Seems like a reasonable reason though. 20161205 03:39:52< vultraz> unit_ability_list should be a type alias 20161205 03:40:22< celticminstrel> Mind you, I'm not quite sure what highest is doing, though from the name I'd guess it's related to std::max_element. 20161205 03:41:55< vultraz> anyway, back to the incredibly tedious work of sorting out this horrendous gui1 code >_> 20161205 03:45:18-!- oldlaptop [~quassel@162.247.150.37] has quit [Remote host closed the connection] 20161205 03:47:28-!- oldlaptop [~quassel@162.247.150.37] has joined #wesnoth-dev 20161205 04:07:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161205 04:16:59-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has joined #wesnoth-dev 20161205 04:27:17-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has quit [Remote host closed the connection] 20161205 04:27:51-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has joined #wesnoth-dev 20161205 04:32:04-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has quit [Ping timeout: 258 seconds] 20161205 04:41:30-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 04:41:30-!- midzer [~quassel@p5B296948.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20161205 04:42:16-!- midzer [~quassel@p5B296948.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161205 04:45:42-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Ping timeout: 246 seconds] 20161205 04:59:53-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 05:03:02-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Read error: Connection reset by peer] 20161205 05:03:22-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 05:22:05-!- h0lybyte [~h0ly@pool-72-90-151-58.nwrknj.east.verizon.net] has joined #wesnoth-dev 20161205 05:50:04-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has joined #wesnoth-dev 20161205 05:54:45-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 248 seconds] 20161205 05:55:03-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev 20161205 05:57:00-!- JyrkiVesterinen [~jyrki@87-100-209-179.bb.dnainternet.fi] has joined #wesnoth-dev 20161205 05:59:08-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has quit [Remote host closed the connection] 20161205 05:59:44-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has joined #wesnoth-dev 20161205 06:04:08-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has quit [Ping timeout: 260 seconds] 20161205 06:10:08-!- Shiki [~Shiki@141.39.226.226] has quit [Quit: Verlassend] 20161205 06:16:53-!- celticminstrel is now known as celmin|ZZzzzzz 20161205 06:47:51-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev 20161205 06:48:38-!- heirecka_ [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev 20161205 06:52:30-!- _laco [~laco@static.183.80.201.138.clients.your-server.de] has quit [Ping timeout: 260 seconds] 20161205 06:52:30-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Ping timeout: 260 seconds] 20161205 06:52:31-!- heirecka_ is now known as heirecka 20161205 06:53:50-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 244 seconds] 20161205 06:59:54-!- _laco_ [~laco@static.183.80.201.138.clients.your-server.de] has joined #wesnoth-dev 20161205 07:04:58-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Ping timeout: 250 seconds] 20161205 07:05:38-!- Nikitaw99 [~Nikitaw99@ppp85-140-3-233.pppoe.mtu-net.ru] has joined #wesnoth-dev 20161205 07:10:32-!- _laco_ is now known as _laco 20161205 07:13:39< vultraz> range-for is one of the absolute best things in c++11. 20161205 07:37:54< Nikitaw99> csharp is funnnnnn 20161205 07:51:16-!- gimemor [~gimemor@host-95-152-34-56.dsl.sura.ru] has joined #wesnoth-dev 20161205 07:57:23< vultraz> YOU get a const reference and YOU get a const reference and YOU get a const reference 20161205 08:02:42-!- Nikitaw99 [~Nikitaw99@ppp85-140-3-233.pppoe.mtu-net.ru] has quit [Quit: I need to go. Bye!] 20161205 08:13:27-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 250 seconds] 20161205 08:22:51-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev 20161205 08:25:56-!- gimemor2 [~gimemor@host-95-152-34-56.dsl.sura.ru] has joined #wesnoth-dev 20161205 08:26:51-!- gimemor [~gimemor@host-95-152-34-56.dsl.sura.ru] has quit [Ping timeout: 260 seconds] 20161205 08:33:54-!- h0lybyte [~h0ly@pool-72-90-151-58.nwrknj.east.verizon.net] has quit [Quit: Leaving.] 20161205 08:37:16-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 250 seconds] 20161205 08:38:43-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev 20161205 08:41:21-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 08:41:21< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Failed 20161205 08:41:21< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-15 20161205 08:41:21< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 08:41:25-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 08:41:35< vultraz> OH COME ON 20161205 08:56:31-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 09:00:37-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Ping timeout: 240 seconds] 20161205 09:02:22-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has joined #wesnoth-dev 20161205 09:02:22-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has quit [Remote host closed the connection] 20161205 09:02:37-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has joined #wesnoth-dev 20161205 09:05:05-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has quit [Read error: Connection reset by peer] 20161205 09:06:13-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has joined #wesnoth-dev 20161205 09:07:33-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 09:07:33< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Succeeded 20161205 09:07:33< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-15 20161205 09:07:33< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 09:07:34-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has quit [Read error: Connection reset by peer] 20161205 09:07:37-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 09:34:08-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 258 seconds] 20161205 09:41:43-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 09:41:43< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Succeeded 20161205 09:41:43< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-16 20161205 09:41:43< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 09:41:47-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 09:45:51-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev 20161205 09:49:43-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 10:04:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20161205 10:08:33-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 10:08:33< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Succeeded 20161205 10:08:33< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-16 20161205 10:08:33< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 10:08:37-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 10:09:32< zookeeper> why is it reporting that again? 20161205 10:10:06< JyrkiVesterinen> It reports four permutations: VS2013 and VS2015, plus Debug and Release. 20161205 10:12:52< zookeeper> well, it's done 7 succeeded reports already? 20161205 10:13:42< JyrkiVesterinen> The reason for that is that no one has committed anything after that commit. 20161205 10:13:54< JyrkiVesterinen> I set AppVeyor to build every 8 hours. 20161205 10:14:17< zookeeper> right 20161205 10:14:22< JyrkiVesterinen> As I thought, AppVeyor runs scheduled builds even if there haven't been new commits. 20161205 10:15:44< zookeeper> is that behavior really useful though? 20161205 10:15:50< zookeeper> besides, think of the carbon footprint :p 20161205 10:16:52< JyrkiVesterinen> I think there isn't much I can do. Before I set up scheduled builds, AppVeyor didn't build the game automatically at all. Apparently some kind of bug. 20161205 10:17:33< JyrkiVesterinen> I could increase the build interval, but I feel 8 hours is already quite long... 20161205 10:18:22< zookeeper> but if it builds automatically on new commits, then can't the interval just be arbitrarily long? 20161205 10:18:48< JyrkiVesterinen> I couldn't get "build automatically on new commits" to work. 20161205 10:19:06< zookeeper> humm. i thought it worked like that based on what i was seeing yesterday. 20161205 10:19:53< zookeeper> as in, it was reporting new builds 1-3 hours after a commit, or something along those lines 20161205 10:26:53-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Read error: Connection reset by peer] 20161205 10:27:11-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 10:29:38-!- JyrkiVesterinen [~jyrki@87-100-209-179.bb.dnainternet.fi] has quit [Quit: Konversation terminated!] 20161205 10:29:40-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Read error: Connection reset by peer] 20161205 10:30:06-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev 20161205 10:34:16-!- RatArmy_ [~ratarmy@133.15.175.65] has quit [Read error: Connection reset by peer] 20161205 10:36:50-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has joined #wesnoth-dev 20161205 10:52:06-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has quit [Read error: Connection reset by peer] 20161205 11:02:48< vultraz> agh 20161205 11:02:55< vultraz> my code is working too precisely! 20161205 11:03:35< vultraz> gui1 dialog shows 13.0% 20161205 11:03:42< vultraz> gui2 shows 12.96% 20161205 11:04:29< vultraz> oh well 20161205 11:04:31< vultraz> precision! 20161205 11:13:53< vultraz> ya know 20161205 11:14:02< vultraz> I wonder if I should just make this a tooltip 20161205 11:14:41< vultraz> perhaps, best, that would be 20161205 11:16:38< vultraz> should probably keep the separate dialog for the graphs 20161205 11:26:47-!- RatArmy_ [~ratarmy@om126237116023.9.openmobile.ne.jp] has joined #wesnoth-dev 20161205 11:44:44< Soliton> vultraz, JyrkiVesterinen: an out-of-line default c/d-tor definition helps the compiler to not have to generate it every time it parses that class/header. adding lots of such definitions sped up compilation considerably at one point. 20161205 12:01:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161205 12:16:34< vultraz> why doesn't one just delete them instead, then, now? 20161205 12:16:40< vultraz> if it's really such a problem 20161205 12:29:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161205 12:44:29-!- JyrkiVesterinen [~JyrkiVest@85-76-110-162-nat.elisa-mobile.fi] has joined #wesnoth-dev 20161205 12:45:56< JyrkiVesterinen> vultraz: If I understand correctly what Soliton says, the compiler needs to generate the destructor if you delete the explicit definition. Thus, _adding_ the definition improves compile time. 20161205 12:46:40< vultraz> I see 20161205 12:56:14< vultraz> JyrkiVesterinen: perhaps you have insight on why the New code here returns 12.96 when the old code returns 13.0 for the same value of prob? http://pastebin.com/zuAjeDwz 20161205 12:56:24< vultraz> (also, why does it show with a blank space before the % sign :/ ) 20161205 12:58:01< vultraz> also, new code doesn't give decimal precision if it's 0. Ie, I get 36, but no 36.0 (as with the old code) 20161205 12:59:09< JyrkiVesterinen> I am more familiar with the snprintf syntax here, mainly for having used string.format() in Lua. 20161205 13:00:16< JyrkiVesterinen> In the old code (%4.1), the 1 (precision) means the number of digits after the decimal point. The 4 is the total number of characters to output, and indeed, "13.0" is four characters. 20161205 13:01:03< JyrkiVesterinen> I don't know offhand how the C++ stream API behaves. 20161205 13:01:13< JyrkiVesterinen> (I find it's very badly designed anyway.) 20161205 13:01:31< JyrkiVesterinen> Have you considered using Boost.Format instead? 20161205 13:01:56< vultraz> no 20161205 13:02:05< vultraz> but I don't think that's necessary for such a small op :P 20161205 13:02:35< vultraz> 12.96 isn't any worse data than 13.0 20161205 13:06:30-!- gimemor2 [~gimemor@host-95-152-34-56.dsl.sura.ru] has quit [Ping timeout: 258 seconds] 20161205 13:08:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161205 13:09:54< JyrkiVesterinen> I found a good tutorial about C++ streams: http://www.learncpp.com/cpp-tutorial/183-output-with-ostream-and-ios/ 20161205 13:10:30< JyrkiVesterinen> Try removing std::setw() and setting the number of digits with std::setprecision() instead. 20161205 13:11:46< JyrkiVesterinen> ss << std::setprecision(3) << 100.0 * prob << '%'; 20161205 13:13:00< JyrkiVesterinen> According to that tutorial, setprecision() sets the number of significant digits if you haven't explicitly set the stream to decimal format. 20161205 13:15:19< vultraz> JyrkiVesterinen: all that accomplishes is getting rid of the space between the numbers and the % sign 20161205 13:15:23< vultraz> still, it's something 20161205 13:16:13< vultraz> still, this result is fine 20161205 13:17:06< JyrkiVesterinen> OK. In that case I'm not going to dig up more information. 20161205 13:17:24< vultraz> thanks anyway 20161205 13:21:27< vultraz> hmm 20161205 13:21:29< vultraz> actually 20161205 13:21:36< vultraz> it seems this result is not acceptable in certain cases 20161205 13:21:38< vultraz> ie 20161205 13:21:46< vultraz> 0.243% 20161205 13:21:51< vultraz> too specific :/ 20161205 13:22:08< vultraz> I shall ask celmin|ZZzzzzz 20161205 13:23:06< JyrkiVesterinen> You can fixate the number of digits after decimal point by using decimal format. 20161205 13:23:30< JyrkiVesterinen> ss << std::fixed << std::setprecision(1) << 100.0 * prob << '%'; 20161205 13:26:20< vultraz> JyrkiVesterinen: that works *exactly* right :D 20161205 14:53:10-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20161205 15:33:05-!- JyrkiVesterinen [~JyrkiVest@85-76-110-162-nat.elisa-mobile.fi] has quit [Quit: .] 20161205 15:51:46-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has joined #wesnoth-dev 20161205 16:07:03-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20161205 16:19:44-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161205 16:21:28< tad_carlucci> 20161204 21:58:31< tad_carlucci> OK. I'm stumped. I'm trying to determine why the test "wesnoth.exe -ucheck_victory_basic_timeout" is failing for VC14. Using a Debug build I get a C Runtime Breakpoint for "list erase iterator outside range" in a callstack having to do with animations. 20161205 16:21:28< tad_carlucci> 20161204 22:02:56< tad_carlucci> ~wesnoth/src/units/animation.cpp line 166 20161205 16:23:40-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2428:b5e9:d7f9:8d5a] has quit [Remote host closed the connection] 20161205 16:25:15< tad_carlucci> vultraz, any idea how to get past this? 20161205 16:35:51-!- celmin|ZZzzzzz is now known as celticminstrel 20161205 16:42:53< tad_carlucci> celticminstrel, I'm unable to debug the WML test failures on Windows because the animation changes a few days ago are so buggy. 20161205 16:44:05-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 16:44:05< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Failed 20161205 16:44:05< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-16 20161205 16:44:05< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 16:44:10-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 16:44:16< celticminstrel> I see. 20161205 16:45:29< tad_carlucci> I think the reason it passes for VS2013 is VS2015 added more runtime checks. 20161205 16:46:27< tad_carlucci> But I can't tell if the animation bugs are the cause of the failure or if they're simply preventing my from finding the cause. 20161205 16:46:40< celticminstrel> Looking at the line in question, it seems like it should be impossible for the iterator to be out of range. 20161205 16:47:02< celticminstrel> Oh wait. 20161205 16:47:12< celticminstrel> branches vs parent->branches 20161205 16:47:43< celticminstrel> Okay, I see. 20161205 16:49:36-!- irker572 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161205 16:49:36< irker572> wesnoth: Celtic Minstrel wesnoth:master 597589fb1019 / src/units/animation.cpp: unit animations: Fix erasing from wrong list https://github.com/wesnoth/wesnoth/commit/597589fb1019829dfdeb0a3793a4fd94f6820d48 20161205 16:49:43< tad_carlucci> I need to switch to windows if I'm going to check it now .. brb 20161205 16:49:46-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.] 20161205 16:50:39-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161205 16:51:31< celticminstrel> Thanks, MSVC 2015. 20161205 16:51:46< celticminstrel> These runtime checks are super-useful. 20161205 16:52:14< tad_carlucci> I wonder how much of that sort of stuff we'd find if we used Debug builds more often? 20161205 16:52:33< mattsc> celticminstrel: Hi. A while ago you seemed to have some minor interest in looking into separating fog and shroud in path finding. Is that something you might do anytime soon(ish) or should I make sure the MAIs work with shroud on the Lua side? 20161205 16:53:36< celticminstrel> I don't think I'm likely to do it before 1.14. What do you mean by making MAIs work with shroud? 20161205 16:54:25< mattsc> Some MAIs don’t work when the AI side is under shroud. 20161205 16:55:09< mattsc> Because terrain under shroud is treated as impassable in the path finder. 20161205 16:55:35-!- h0lybyte [~h0ly@pool-108-53-77-116.nwrknj.fios.verizon.net] has joined #wesnoth-dev 20161205 16:56:22-!- h0lybyte [~h0ly@pool-108-53-77-116.nwrknj.fios.verizon.net] has left #wesnoth-dev [] 20161205 16:57:01< celticminstrel> That could probably be changed with a different cost function... 20161205 16:57:08-!- gimemor [~gimemor@host-95-152-34-56.dsl.sura.ru] has joined #wesnoth-dev 20161205 16:59:19< mattsc> Possibly. But I know how to fix it otherwise (by ignoring shroud while taking hidden units off the map, as discussed previously), it’s not even all that difficult and I already have tested it, but I don’t want to do this if in the near future it becomes unnecessary because the path finding code can do it too. 20161205 16:59:52< mattsc> But if you’re not planning to do this before 1.14, then I’ll do it in the AI code, that’s not a problem. 20161205 17:00:15< mattsc> I should be able to get it in before 1.13.7. The main effort is in testing, not coding. 20161205 17:00:24< celticminstrel> The pathfinding in question is called from C++ or from Lua? 20161205 17:00:53< mattsc> Using wesnoth.find_path()/ 20161205 17:01:15< mattsc> which, you told me at some point, calls the a* search directly. 20161205 17:01:39-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20161205 17:03:03< celticminstrel> I assume there's a good reason not to use a cost function instead of the pathfinding options table? 20161205 17:03:13< celticminstrel> ...why is that underlined. 20161205 17:04:36< mattsc> because you’d have to replicate the entire default cost function — which has a lot more details to it than just the terrain cost IIRC 20161205 17:05:03< mattsc> I don’t see the point in replicating all that 20161205 17:05:08< celticminstrel> Right. 20161205 17:06:26< celticminstrel> Is it possible to fallback to ignoring shroud only if pathfinding with it fails? 20161205 17:06:56< celticminstrel> Anyway, I guess ignoring shroud while temporarily removing hidden units sounds fine. 20161205 17:07:07< celticminstrel> As long as it's documented that the AI ignores shroud. 20161205 17:07:26< celticminstrel> And of course, only for micro AIs, not for CAs used by the core AI. 20161205 17:07:28< mattsc> I think it’s possible, but not necessary; because it will always fail when there’s shroud. 20161205 17:07:36< celticminstrel> What? 20161205 17:07:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 17:07:56< celticminstrel> Which MAIs are affected? 20161205 17:08:04< mattsc> I should be more precise: it will always fail to shrouded hexes 20161205 17:08:20< celticminstrel> Right. 20161205 17:08:31< mattsc> and if the hexes are not shrouded, there’s no difference between ignoring shroud and not 20161205 17:08:40< mattsc> hmm, no, I guess that’s not true 20161205 17:09:11< celticminstrel> Shroud implies a longer route may be taken even though a shorter one exists, because the shorter route is not known. 20161205 17:09:18< celticminstrel> As in, unexplored. 20161205 17:09:34< celticminstrel> Of course, that assumes the destination is unshrouded. 20161205 17:09:40< mattsc> right, that’s what I meant with my last comment 20161205 17:09:42< celticminstrel> If the destination is shrouded, it won't make any difference. 20161205 17:09:59< celticminstrel> BTW, did you see PR 881? 20161205 17:10:04< mattsc> but the default behavior for the Wesnoth AIs is to ignore shroud, so I don’t see why the Micro AIs default behavior needs to be (or even should be) different 20161205 17:11:00< celticminstrel> Oh right. 20161205 17:11:05< mattsc> I saw it — but that’s all I’ve had time for so far. 20161205 17:11:26< mattsc> It’s on my list, but … Was there anything specific you wanted me to do about it, or just general testing? 20161205 17:11:48-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 17:11:49< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug ln-zookeeper 8fdf689: Added macro NEW:OVERLAY and used it to place most terrain overlays Succeeded 20161205 17:11:49< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-16 20161205 17:11:49< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/8fdf689681ce03edf7aea44f24981614ca49157f 20161205 17:11:52-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 17:12:11< celticminstrel> I guess just general testing? There's [modify_ai], [modify_side]switch_ai, and [modify_side][ai] IIRC 20161205 17:12:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20161205 17:12:35< celticminstrel> I mean, you can also test the other tags if you want, and the other [modify_side] stuff, but I pinged you mainly for the AI-related stuff. 20161205 17:13:00< mattsc> yeah, that’s how I took it; and the timescale to get this in? For 1.13.7? 20161205 17:13:03< celticminstrel> Also I think [modify_side][ai] should now be able to add goals IIRC, not that that's really important. 20161205 17:13:13< mattsc> ok 20161205 17:13:59< mattsc> I’ll try to get to it sometime this week; my time (and energy) for Wesnoth is very limited at the moment. 20161205 17:14:08< celticminstrel> There's no hurry. 20161205 17:14:24< celticminstrel> I still have more stuff I want to add to that branch that I haven't gotten around to yet. 20161205 17:14:33< mattsc> Okay; if I wait too long, it gets more and more likely that I won’t do it though. :P 20161205 17:14:50< celticminstrel> I'd probably remind you if it took a long enough time. 20161205 17:14:59< mattsc> sounds good 20161205 17:15:13< mattsc> Btw, did you see my comment yesterday that I can compile with Xcode? 20161205 17:15:30< celticminstrel> Yeah. I saw. 20161205 17:15:40< celticminstrel> Did I commit the readdition of libintl? 20161205 17:16:03< celticminstrel> Looks like I did. 20161205 17:16:46< mattsc> Okay, good. I am off to other, less exciting things then. I’ll try to look at the PR and get the MAI/shroud fix done before 1.13.7. 20161205 17:20:40-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20161205 17:22:08< tad_carlucci> celticminstrel, So far so good. The Debug build runs. Waiting for a Release build to finish to get back to testing. 20161205 17:23:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 17:46:33-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 17:46:33< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release Celtic Minstrel 597589f: unit animations: Fix erasing from wrong list Succeeded 20161205 17:46:33< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-17 20161205 17:46:33< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/597589fb1019829dfdeb0a3793a4fd94f6820d48 20161205 17:46:38-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 17:56:22-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Switching to Unix to get some real work done.] 20161205 17:56:27-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161205 17:57:25-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 18:00:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds] 20161205 18:08:14< irker572> wesnoth: Celtic Minstrel wesnoth:wml_tag_porting 145fd73f55b8 / / (8 files in 4 dirs): Properly port [modify_side] to Lua https://github.com/wesnoth/wesnoth/commit/145fd73f55b8b15ee7867fdab70947dce05dbadf 20161205 18:08:16< irker572> wesnoth: Celtic Minstrel wesnoth:wml_tag_porting 1d16d7122c19 / data/lua/wml-tags.lua src/ai/manager.cpp src/scripting/game_lua_kernel.cpp: Properly port [modify_ai] to Lua https://github.com/wesnoth/wesnoth/commit/1d16d7122c198405c67033423942f77d0adba404 20161205 18:08:18< irker572> wesnoth: Celtic Minstrel wesnoth:wml_tag_porting 79ef21154d91 / / (4 files in 4 dirs): Properly port [heal_unit] to Lua https://github.com/wesnoth/wesnoth/commit/79ef21154d91188a36d419171c4cf85631b238fe 20161205 18:08:20< irker572> wesnoth: Celtic Minstrel wesnoth:wml_tag_porting 35fcd122cfda / changelog data/lua/wml/message.lua src/scripting/game_lua_kernel.cpp: wesnoth.scroll_to_tile can now skip if onscreen https://github.com/wesnoth/wesnoth/commit/35fcd122cfda601deb6d0bf5825e38ae061f6999 20161205 18:08:22< irker572> wesnoth: Celtic Minstrel wesnoth:wml_tag_porting b571c74bd53d / / (7 files in 5 dirs): WIP port of [animate_unit] https://github.com/wesnoth/wesnoth/commit/b571c74bd53debcdc12ea05f75aa694f0bae6e77 20161205 18:11:08-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev 20161205 18:11:08< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug Celtic Minstrel 597589f: unit animations: Fix erasing from wrong list Succeeded 20161205 18:11:08< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-17 20161205 18:11:08< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/597589fb1019829dfdeb0a3793a4fd94f6820d48 20161205 18:11:13-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev [] 20161205 18:27:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds] 20161205 18:28:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161205 18:28:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit] 20161205 18:29:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161205 18:33:49-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161205 18:34:32-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 265 seconds] 20161205 18:38:25-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161205 18:39:22< tad_carlucci> celticminstrel, How odd. Your recent commit for animations appears to have fixed the failures for WML unit tests 20161205 18:40:15< celticminstrel> Why is that so odd? 20161205 18:41:23-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161205 18:41:41< celticminstrel> Not that I specifically expected it to, but... 20161205 18:42:09< celticminstrel> I did at least expect it to fix the list iterator not in range problem, so if all the test failures were from that, then it makes sense... 20161205 18:42:10< tad_carlucci> Vistory not occurring timeout not happening was caused by a problem deleting an animation. It's Dirk Gently Holistic Programming .. Everything is Connected 20161205 18:48:00< tad_carlucci> So, by reckoning, in about 7 hours we should see 4 out of 4 succeeded instead on only 3 out of 4. 20161205 18:49:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 19:01:35-!- JyrkiVesterinen [~jyrki@87-92-35-182.bb.dnainternet.fi] has joined #wesnoth-dev 20161205 19:06:21< tad_carlucci> JyrkiVesterinen, I saw a comment that you'd had problems getting AppVeyor to build on push. The only issue I had with that was avoiding the double-build on pushing a PR to a subject branch and I solved that. 20161205 19:08:09< JyrkiVesterinen> I noticed that your AppVeyor project indeed was able to build on push. 20161205 19:08:41< JyrkiVesterinen> I had no way to investigate the problem, so I just decided to turn on scheduled builds and forget about it. 20161205 19:09:45< tad_carlucci> If you're wanting to change I'll set up again and make careful notes. I'm wanting to wait until we're back to 4 success .. whihc I'm thinking will be next batch 20161205 19:09:46-!- travis-ci [~travis-ci@ec2-54-92-137-167.compute-1.amazonaws.com] has joined #wesnoth-dev 20161205 19:09:47< travis-ci> wesnoth/wesnoth#12306 (master - 597589f : Celtic Minstrel): The build has errored. 20161205 19:09:47< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/181400581 20161205 19:09:47-!- travis-ci [~travis-ci@ec2-54-92-137-167.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161205 19:11:17< JyrkiVesterinen> I think it's not the way the project was configured. It should be simple: AppVeyor builds on push unless scheduled builds are enabled. Nothing else should matter. 20161205 19:12:09< JyrkiVesterinen> And I kept the schedule text field empty until I enabled scheduled builds. 20161205 19:17:13< tad_carlucci> celticminstrel, That last travis build passed all Linux but failed OS/x due to runtime quota 20161205 19:17:47< celticminstrel> Oh my. 20161205 19:18:30< tad_carlucci> There were a lot of messages you might want to look at. "No symbols" and such but it looks like it just took too long. May be a temporary issue. 20161205 19:20:50-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Switching to Unix to get some real work done.] 20161205 19:21:39-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161205 19:21:51-!- gfgtdf [~chatzilla@x4e363a9e.dyn.telefonica.de] has joined #wesnoth-dev 20161205 19:21:57< gfgtdf> any opinion on pr #895 ? 20161205 19:22:25< celticminstrel> What was that about again. 20161205 19:22:39< celticminstrel> Unless it was just opened now, in which case I haven't even seen it yet. 20161205 19:23:35< tad_carlucci> Is it two subjects? The utils stuff and the lua stuff? 20161205 19:23:51< gfgtdf> just opened 20161205 19:24:01< gfgtdf> tad_carlucci: yes they are unrelated 20161205 19:24:12< celticminstrel> Then I'll look at it in an hour or so probably. 20161205 19:25:27< tad_carlucci> OK. Consider theself dinged for that. After a quick read-through I don't see any issues. I'd wait to be sure Travis doesn't spot any ultra-lameness, though. 20161205 19:25:38-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161205 19:28:15-!- heirecka_ [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev 20161205 19:28:39-!- Netsplit *.net <-> *.split quits: heirecka, prkc, APic 20161205 19:28:42< gfgtdf> tad_carlucci: yes ofcourse. 20161205 19:29:36-!- heirecka_ is now known as heirecka 20161205 19:34:21-!- APic [apic@apic.name] has joined #wesnoth-dev 20161205 19:37:12-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev 20161205 19:47:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161205 19:51:30-!- gimemor [~gimemor@host-95-152-34-56.dsl.sura.ru] has quit [Ping timeout: 246 seconds] 20161205 20:05:44-!- travis-ci [~travis-ci@ec2-54-147-34-26.compute-1.amazonaws.com] has joined #wesnoth-dev 20161205 20:05:45< travis-ci> wesnoth/wesnoth#12307 (wml_tag_porting - b571c74 : Celtic Minstrel): The build is still failing. 20161205 20:05:45< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/181423644 20161205 20:05:45-!- travis-ci [~travis-ci@ec2-54-147-34-26.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161205 20:19:19< zookeeper> hmhmhm... https://dl.dropboxusercontent.com/u/63964618/wesnoth/lavalice.gif 20161205 20:19:33< celticminstrel> Lava lice? 20161205 20:19:47< celticminstrel> Sounds like a great idea for a new monster. 20161205 20:20:19< celticminstrel> Rolls up when you attack it. 20161205 20:20:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161205 20:20:57< zookeeper> well, sure. that one's just because i recorded it with licecap, though :p 20161205 20:40:02-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev 20161205 20:46:07-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.] 20161205 21:03:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 21:08:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds] 20161205 21:08:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 21:08:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161205 21:08:31-!- irker572 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161205 21:08:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 21:17:35-!- JyrkiVesterinen [~jyrki@87-92-35-182.bb.dnainternet.fi] has quit [Quit: .] 20161205 21:35:36-!- knotwork [~markm@99.192.95.6] has joined #wesnoth-dev 20161205 21:35:36-!- knotwork [~markm@99.192.95.6] has quit [Changing host] 20161205 21:35:36-!- knotwork [~markm@unaffiliated/knotwork] has joined #wesnoth-dev 20161205 21:37:57< gfgtdf> does anyone know what i do wrong? when i do "git push wesnoth master" it tells me "Updates were rejected because a pushed branch tip is behind its remote" but when i do "git pull wesnoth master" it tells me "Already up-to-date" 20161205 21:42:40-!- irker067 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161205 21:42:40< irker067> wesnoth: gfgtdf wesnoth:master c003bc1e18e8 / src/units/animation.cpp: remove some utils::split https://github.com/wesnoth/wesnoth/commit/c003bc1e18e82a7e4a06f55668f0a6fe66fcd023 20161205 21:42:44< gfgtdf> ok found the issue. 20161205 21:46:49< vultraz> huh 20161205 21:50:41-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Remote host closed the connection] 20161205 21:55:23< vultraz> zookeeper: lava looks great, but too fast 20161205 21:55:42< vultraz> at that speed it looks like wiggly jello 20161205 22:09:45< Aginor> gfgtdf: what was the issue? 20161205 22:09:55< Aginor> gfgtdf: it sounds like an interesting problem 20161205 22:10:34< gfgtdf> Aginor: i was on anther branch and push does not use the current branch by deafutl, i had to use "push wesnoth my_branch:master" 20161205 22:17:40< Aginor> right, yes 20161205 22:20:30< zookeeper> vultraz, yeah. i was hoping 8 frames would be enough, but it's kind of too fast then and increasing the frame interval makes it too choppy. 20161205 22:25:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161205 22:25:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 22:30:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds] 20161205 22:31:27< vultraz> 24 frames neeeded 20161205 22:31:49-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV] 20161205 22:32:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161205 22:32:56< zookeeper> ... 20161205 22:32:59< zookeeper> no, not 24 20161205 22:37:05-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Read error: Connection reset by peer] 20161205 22:38:58-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev 20161205 22:42:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161205 22:42:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161205 22:45:29< zookeeper> although, doubling it to 16 with simple fade frames in between seems to work surprisingly nicely 20161205 22:47:39-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Read error: Connection reset by peer] 20161205 22:47:53-!- louis94 [~~louis94@91.178.240.133] has joined #wesnoth-dev 20161205 22:48:25-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev 20161205 22:52:39< celticminstrel> zookeeper: The lava looks great BTW. Apart from the speed. 20161205 22:56:16< gfgtdf> the compiler at http://cpp.sh/ prints 8 for sizeof(std::string), how can this be? i thought all compilers do short strign optimisatiosn these days, also even if not, it shoudl still need 1 char* or the data and 2 size_type for the allocated size and the string size. which already gives a size of 12. 20161205 22:57:42< gfgtdf> hmm mabye this realy uses a non sso implementation 20161205 22:57:58< gfgtdf> but thi is c++14, which afaik forbids the cow implementation- 20161205 22:59:33< celticminstrel> How do you get 12 from a char* and two size_t. 20161205 23:00:27< gfgtdf> celticminstrel: assuming 32 bit system. 20161205 23:00:34< celticminstrel> Also, there's no particular reason why it has to be a 32-bit system. 20161205 23:00:59< celticminstrel> Ah, right, I was thinking of a 64-bit system when I came up with 24. 20161205 23:01:29< celticminstrel> If it were a 16-bit system, a size of 8 would seem quite reasonable. 20161205 23:02:15< celticminstrel> That said, worrying about this is kind of pointless. You shouldn't be relying on the size of std::string anyway. 20161205 23:02:41< gfgtdf> celticminstrel: you know whats the oldest version of gcc we support ? 20161205 23:03:14< celticminstrel> I can't remember if it was 4.8 or 4.9. 20161205 23:03:34< celticminstrel> Probably the former? 20161205 23:03:45< gfgtdf> celticminstrel: ok thx 20161205 23:12:25-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20161205 23:21:43< vultraz> 4.8 20161205 23:21:58< vultraz> but it should be 5 if it weren't for *(&@*(&(#&*(#&@(**)!@#&&*)^!#&*^ debian 20161205 23:42:35< zookeeper> matthiaskrgr, btw, what does woptipng do if it encounters an 8 bpp png? i take it that it only saves 32/24bpp, so will it just try to compress as 24bpp and see that the output becomes bigger than the input and skip it? 20161205 23:43:04< DeFender1031> is woptipping anything like cowtipping? 20161205 23:43:14< zookeeper> yes it's actually the same thing 20161205 23:43:24< zookeeper> just a different word for it 20161205 23:43:25< DeFender1031> awesoooooome! 20161205 23:43:43< DeFender1031> :P 20161205 23:48:43< celticminstrel> XD What 20161205 23:49:11< matthiaskrgr> uhmm 20161205 23:51:37< matthiaskrgr> I guess it depends on how the underlaying tools/programs handle 8 bpp ? 20161205 23:52:10< matthiaskrgr> but yes, in theory it should skip it if compression fails in a way the image gets larger in size 20161205 23:54:00< zookeeper> mmkay --- Log closed Tue Dec 06 00:00:33 2016