--- Log opened Wed Nov 23 00:00:16 2016
20161123 00:01:27-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161123 00:32:46-!- gfgtdf [~chatzilla@x4e36890a.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161123 00:38:54< Aginor> I'm disturbed that there is such a thing as a "normal" travis hang
20161123 00:39:33< Aginor> it usually seems to be during the tests too, which makes me wonder if there's been a regression and we just blame it on travis
20161123 00:40:32< vultraz> tests are known to randomly fail
20161123 00:40:36< vultraz> we have no idea why it happens
20161123 00:40:37< vultraz> so we ignore it
20161123 00:44:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161123 00:45:14-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 00:47:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20161123 00:53:23-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Ping timeout: 245 seconds]
20161123 00:59:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 00:59:29< Aginor> has anyone spent effort in trying to reproduce the same random failures outside travis?
20161123 01:03:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161123 01:04:44-!- gfgtdf [~chatzilla@x4e36890a.dyn.telefonica.de] has joined #wesnoth-dev
20161123 01:07:42< vultraz> not sure
20161123 01:07:44< vultraz> does it matter?
20161123 01:08:37< vultraz> i think it was looked into, but no concrete cause found
20161123 01:09:31< Aginor> I think it matters if it's a genuine problem
20161123 01:09:48< vultraz> it only seems to affect travis 
20161123 01:09:55< Aginor> actually, I think it also matters if we think that we cannot trust our CI tool
20161123 01:10:43< Aginor> because it trains us to accept failures as the normal case, not the exception
20161123 01:10:58< celticminstrel> Well, it does say errored rather than failed though.
20161123 01:11:52-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has joined #wesnoth-dev
20161123 01:12:47< vultraz> travis is in failure mode more than passing mode, tbh
20161123 01:13:00< celticminstrel> Since when?
20161123 01:13:04< vultraz> usually
20161123 01:14:21< gfgtdf> but 'error' doesnt necessarily mena its traiv fault, it coudl also mean for exmapel that one of the tests go stuck becaue our code it waiting for something infiniteley.
20161123 01:14:33< gfgtdf> iirc this happen multiple times with the mp tests.
20161123 01:15:00< celticminstrel> Yeah.
20161123 01:19:33-!- Greg-Boggs [~greg_bogg@c-73-37-7-188.hsd1.or.comcast.net] has joined #wesnoth-dev
20161123 01:47:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161123 01:47:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161123 01:53:06-!- Greg-Boggs [~greg_bogg@c-73-37-7-188.hsd1.or.comcast.net] has quit [Ping timeout: 250 seconds]
20161123 01:53:17-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has quit [Ping timeout: 256 seconds]
20161123 02:06:22-!- JyrkiVesterinen [~JyrkiVest@87-100-160-161.bb.dnainternet.fi] has joined #wesnoth-dev
20161123 02:10:22-!- Greg-Boggs [~greg_bogg@c-73-37-7-188.hsd1.or.comcast.net] has joined #wesnoth-dev
20161123 02:11:09-!- Greg-Boggs [~greg_bogg@c-73-37-7-188.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20161123 02:16:36-!- gfgtdf_ [~chatzilla@x4e3697d0.dyn.telefonica.de] has joined #wesnoth-dev
20161123 02:18:44-!- gfgtdf [~chatzilla@x4e36890a.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161123 02:18:46-!- gfgtdf_ is now known as gfgtdf
20161123 02:22:16-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has joined #wesnoth-dev
20161123 02:34:53-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has quit [Quit: Konversation terminated!]
20161123 02:50:35< Aginor> gfgtdf greatly illustrates the point that I was trying to make; we don't know what the reason for the failures are unless we take them seriously
20161123 02:51:05< celticminstrel> I don't know if anyone considered talking to Travis people about it.
20161123 02:51:14< celticminstrel> I never heard of anything though.
20161123 03:16:09-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161123 03:45:37-!- irker517 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161123 03:45:37< irker517> wesnoth: gfgtdf wesnoth:master dc2b40fd2f6d / src/help/help_topic_generators.cpp: skip nameless traits in unit help pages https://github.com/wesnoth/wesnoth/commit/dc2b40fd2f6d7a7771599b334be409933cb7c545
20161123 04:03:57-!- gfgtdf [~chatzilla@x4e3697d0.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 50.0/20161104212021]]
20161123 04:09:59-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161123 04:19:03-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20161123 04:19:14-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20161123 04:19:24-!- VultCave is now known as vultraz
20161123 04:28:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 04:33:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20161123 04:51:25-!- travis-ci [~travis-ci@ec2-54-205-230-247.compute-1.amazonaws.com] has joined #wesnoth-dev
20161123 04:51:26< travis-ci> wesnoth/wesnoth#12142 (master - dc2b40f : gfgtdf): The build has errored.
20161123 04:51:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/178182049
20161123 04:51:27-!- travis-ci [~travis-ci@ec2-54-205-230-247.compute-1.amazonaws.com] has left #wesnoth-dev []
20161123 05:17:51-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 256 seconds]
20161123 05:19:46-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20161123 05:53:02-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161123 06:05:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 06:08:35-!- Appleman1234_ [~Appleman1@KD106161201080.au-net.ne.jp] has joined #wesnoth-dev
20161123 06:08:37-!- Appleman1234 [~Appleman1@KD106161210210.au-net.ne.jp] has quit [Ping timeout: 248 seconds]
20161123 06:10:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 258 seconds]
20161123 06:11:35-!- Appleman1234_ [~Appleman1@KD106161201080.au-net.ne.jp] has quit [Client Quit]
20161123 06:12:19-!- Appleman1234 [~Appleman1@KD106161201080.au-net.ne.jp] has joined #wesnoth-dev
20161123 06:45:53-!- irker517 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161123 07:15:35-!- JyrkiVesterinen [~JyrkiVest@87-100-160-161.bb.dnainternet.fi] has quit [Quit: .]
20161123 07:29:50-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161123 07:54:09-!- celticminstrel is now known as celmin|sleep
20161123 08:03:33-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has joined #wesnoth-dev
20161123 08:10:30< vultraz> tfw you try to make GUI2 use the simpler SDL_Color instead of unit32_t and end up making everything blue p_p
20161123 08:15:37< vultraz> ahh
20161123 08:15:38< vultraz> ok, simple fix
20161123 08:15:44< vultraz> pango_text::set_foreground_color wasn't considering alpha
20161123 08:16:48< vultraz> now, just need to figure out these "narrowing conversion" warnings
20161123 08:17:03< vultraz> JyrkiVesterinen: what does "narrowing conversion" even mean?
20161123 08:17:57< JyrkiVesterinen> Narrowing conversion means converting from a relatively wide type (e.g. int) to a narrower type (e.g. char).
20161123 08:18:10< vultraz> hm, I see
20161123 08:18:11< JyrkiVesterinen> Doing so requires discarding some of most significant bits.
20161123 08:18:36< JyrkiVesterinen> Narrowing conversions are perfectly allowed in C++, but the compiler isn't sure if you really want to do it.
20161123 08:18:51< JyrkiVesterinen> If you do, cast the value to the target type explicitly.
20161123 08:19:18< JyrkiVesterinen> my_function(static_cast<char>(my_int)); or something like that.
20161123 08:20:35< vultraz> hm
20161123 08:20:51< vultraz> seems if i cast to Uint8 the colors don't appear at all
20161123 08:21:05< vultraz> but if i cast to unsigned int, they do, but I get narrowing warnings :/
20161123 08:21:19< vultraz> (trying to convert a string to SDL_Color members)
20161123 08:21:33< JyrkiVesterinen> Show the code.
20161123 08:22:09< vultraz> http://pastebin.com/BJiGyvZZ
20161123 08:30:10 * JyrkiVesterinen is trying to check SDL documentation about SDL_Color. It's proving quite hard: Internet connection is very slow here, and worse, another program is taking nearly all bandwidth he does have... 
20161123 08:31:00< vultraz> SDL_Color is made up of Uint8s
20161123 08:31:34< JyrkiVesterinen> In that case, casting to Uint8s should work.
20161123 08:32:16< JyrkiVesterinen> Really, this sounds like your code somehow relies on narrowing conversion to work. :(
20161123 08:33:14< vultraz> it builds without warnings, but then stuff like text and lines are barely visible - ie, the color is wrong.
20161123 08:33:16< JyrkiVesterinen> In other words: if you lexical_cast to unsigned int (32-bit unsigned integer), then the compiler implicitly converts the unsigned int to Uint8 by discarding the first 24 bits, and that somehow gives the right value.
20161123 08:33:46< JyrkiVesterinen> Whereas lexical_casting to Uint8 directly gives wrong values.
20161123 08:34:43< JyrkiVesterinen> Maybe the implementation of lexical_cast() is broken?
20161123 08:35:01< vultraz> depends
20161123 08:35:05< vultraz> there are two implementations :/
20161123 08:36:27< JyrkiVesterinen> In any case, I suggest you to convert the strings with std::stoul() instead and cast the result to Uint8 separately.
20161123 08:36:51< JyrkiVesterinen> static_cast<Uint8>(std::stoul(fields[0])
20161123 08:38:51< vultraz> seems to work
20161123 08:38:52< vultraz> thanks
20161123 08:40:06-!- irker425 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161123 08:40:06< irker425> wesnoth: Charles Dang wesnoth:master b95be124e0e1 / data/gui/window/campaign_dialog.cfg src/gui/dialogs/campaign_selection.cpp: Campaign Dialog: code cleanup, including the removal of the old listbox code https://github.com/wesnoth/wesnoth/commit/b95be124e0e19d604e78de07398431744184aef3
20161123 08:40:09< irker425> wesnoth: Charles Dang wesnoth:master c6fbe9a94cb3 / src/font/text.cpp: Pango Text: made the set_foreground_color for SDL_Color handle alpha https://github.com/wesnoth/wesnoth/commit/c6fbe9a94cb3892307b804686d267819caebe8cd
20161123 08:40:12< irker425> wesnoth: Charles Dang wesnoth:master 3203a8de1037 / src/gui/ (7 files in 2 dirs): GUI2: convert internal color handling to use SDL_Color https://github.com/wesnoth/wesnoth/commit/3203a8de1037b9a645ef007d1910b57cc2339333
20161123 08:40:17< vultraz> Aginor: ^
20161123 08:50:29< iceiceice> JyrkiVesterinen, it might be that the stream does something unintuitive when converting out of range values to uint8
20161123 08:51:11< iceiceice> i dont remember what its supposed to do in cases like that
20161123 08:51:30< iceiceice> lexical cast only reports an error if the stream is set to "fail" state
20161123 08:51:55< JyrkiVesterinen> I figure that values passed to decode_color() should be in range nearly all the time, though.
20161123 08:52:34< iceiceice> hmm
20161123 08:52:49< iceiceice> maybe add some tests to the unit test target, and see if they fail on whatever platform vultraz is using?
20161123 08:53:05< iceiceice> lexical cast should be pretty easy to test
20161123 08:53:13< iceiceice> probly we already have some tests (?)
20161123 08:53:14< vultraz> windows, which travis isn't running.
20161123 08:53:30< iceiceice> if u use mingw it should be quite similar to the gcc build
20161123 08:53:48< vultraz> oh, true
20161123 08:53:52< vultraz> i do use tdm gcc
20161123 08:54:33< iceiceice> i guess u could add a mingw build to travis
20161123 08:54:39< iceiceice> if you felt like it
20161123 08:54:54< iceiceice> and run the tests in wine (?)
20161123 08:55:01< iceiceice> i think that's not all that valuable though
20161123 08:55:08< JyrkiVesterinen> tad_carlucci is working on setting up AppVeyor, which builds the game with Visual Studio.
20161123 08:59:02-!- prkc [~prkc@46.166.190.224] has quit [Remote host closed the connection]
20161123 09:31:27-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161123 09:35:06-!- Duthlet [~Duthlet@dslb-146-060-035-062.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20161123 09:41:36-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161123 09:41:51-!- travis-ci [~travis-ci@ec2-54-205-230-247.compute-1.amazonaws.com] has joined #wesnoth-dev
20161123 09:41:52< travis-ci> wesnoth/wesnoth#12143 (master - 3203a8d : Charles Dang): The build passed.
20161123 09:41:53< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/178220423
20161123 09:41:53-!- travis-ci [~travis-ci@ec2-54-205-230-247.compute-1.amazonaws.com] has left #wesnoth-dev []
20161123 09:49:30-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has joined #wesnoth-dev
20161123 10:11:53-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161123 10:12:06-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit]
20161123 10:18:17-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has quit [Ping timeout: 240 seconds]
20161123 10:57:23-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has joined #wesnoth-dev
20161123 10:58:51-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has quit [Quit: .]
20161123 11:07:11-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has quit [Ping timeout: 260 seconds]
20161123 11:09:41-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has joined #wesnoth-dev
20161123 11:33:16-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161123 11:37:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 11:38:23-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has quit [Ping timeout: 245 seconds]
20161123 11:41:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20161123 11:41:28-!- irker425 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161123 11:59:11-!- astrelyon [~astrelyon@dh207-127-221.xnet.hr] has joined #wesnoth-dev
20161123 12:06:34-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has joined #wesnoth-dev
20161123 12:16:19-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161123 12:19:39-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161123 12:19:53-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20161123 12:21:25-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161123 12:31:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 12:36:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20161123 14:02:05-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161123 14:04:24-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161123 14:04:41-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit]
20161123 14:29:57-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161123 14:30:06-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit]
20161123 14:33:30< vultraz> i wonder if there would ever be a reason to use std::for_each instead of a range-for loop.
20161123 14:34:34< JyrkiVesterinen> The situation is if you have an existing function that does what you want to do for every element.
20161123 14:35:00< JyrkiVesterinen> Even in that situation I'd use range-for, though. It's more intuitive code in my opinion.
20161123 14:35:28< vultraz> ahh
20161123 14:47:09-!- irker108 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161123 14:47:09< irker108> wesnoth: Charles Dang wesnoth:master 376925bc9b5d / / (8 files in 5 dirs): Converted Terrain Layers dialog to GUI2 https://github.com/wesnoth/wesnoth/commit/376925bc9b5d55ed2c34383c7c659de10d1db0f1
20161123 14:47:47< zookeeper> whoops. upkeep= is not part of SUF. no wonder there's a bug with my code that assumes that in, ahem, 12 places.
20161123 14:48:58-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161123 14:53:12< irker108> wesnoth: gfgtdf wesnoth:master 9f014825a1d6 / src/help/help_topic_generators.cpp: skip musthave nameless traits in unit help pages trait count https://github.com/wesnoth/wesnoth/commit/9f014825a1d63398f4b5bccf75ba12abb15b9fd4
20161123 14:56:31-!- gfgtdf [~chatzilla@x4e3697d0.dyn.telefonica.de] has joined #wesnoth-dev
20161123 15:07:06-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161123 15:08:51< gfgtdf> vultraz: any opiion on addon a 'wesnoth.register_widget_definition' function?
20161123 15:09:07< vultraz> possibly a good idea
20161123 15:09:34< vultraz> might want to talk to celmin|sleep since he has some ideas for revamping the lua gui stuff
20161123 15:12:16< gfgtdf> vultraz: another approach woudl be t allow [definition] tags directly in widgets lwik [buttion], but im currently leaning more towards the register_widget_definition function approach
20161123 15:16:05< gfgtdf> made a bugrpeort so that i wont forget https://gna.org/bugs/index.php?25337
20161123 15:31:57-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161123 15:35:03-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit]
20161123 15:54:38-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has quit [Quit: .]
20161123 16:09:39< vultraz> hmmm
20161123 16:09:57< vultraz> I just realized sdl::string_to_color is now essentially the same as gui2::decode_color
20161123 16:10:54< vultraz> ah, wait
20161123 16:11:01< vultraz> no, it does other weirdness...
20161123 16:12:36< vultraz> hmmm
20161123 16:12:45< vultraz> actually, I think this is useless
20161123 16:13:13< vultraz> let's see
20161123 16:13:27< vultraz> ignoring the fact that help has its own string_to_color...
20161123 16:13:30< vultraz> we have..
20161123 16:14:34< vultraz> [label], [print], floating labels... (is this [floating_text]?)
20161123 16:14:37< vultraz> that's it
20161123 16:14:56< vultraz> first two use RGB color= keys, just like GUI2
20161123 16:15:52< vultraz> ok, the latter IS floating text
20161123 16:17:38< vultraz> or, well, is used by it
20161123 16:18:01< vultraz> but yeah, it seems to be in the same color= (or red= green= blue=) format
20161123 16:18:25< vultraz> in which case, I think gui2::decode_color can replace sdl::string_to_color
20161123 16:18:59< vultraz> int_to_color is used much more liberally
20161123 16:20:48< vultraz> (sdl::string_to_color appears to be converting a string to uint32_t and then to SDL_Color via calling string2rbg... whyyy)
20161123 16:23:05< vultraz> #JustWesnothCodebaseThings
20161123 16:31:52-!- travis-ci [~travis-ci@ec2-54-226-182-183.compute-1.amazonaws.com] has joined #wesnoth-dev
20161123 16:31:53< travis-ci> wesnoth/wesnoth#12145 (master - 9f01482 : gfgtdf): The build was broken.
20161123 16:31:53< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/178310724
20161123 16:31:53-!- travis-ci [~travis-ci@ec2-54-226-182-183.compute-1.amazonaws.com] has left #wesnoth-dev []
20161123 16:41:06< gfgtdf> vultraz: https://github.com/wesnoth/wesnoth/commit/376925bc9b5d55ed2c34383c7c659de10d1db0f1 breaks travis
20161123 16:41:29< gfgtdf> vultraz: somethign with 'terrain_layers::display' and 'class display;'
20161123 17:07:37< vultraz> dammit
20161123 17:07:46< vultraz> even though i used a type alias 
20161123 17:09:12< vultraz> gcc 4 sucks
20161123 17:10:49< vultraz> it literally only fails on gcc too :|
20161123 17:11:12< vultraz> curse curse curse gcc 4
20161123 17:18:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 17:21:25-!- JyrkiVesterinen [~JyrkiVest@89-166-117-85.bb.dnainternet.fi] has joined #wesnoth-dev
20161123 17:21:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161123 17:21:45-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161123 17:32:15-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Ping timeout: 256 seconds]
20161123 17:34:48-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161123 17:34:55-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161123 17:37:44-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161123 17:41:17-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161123 17:53:19-!- irker108 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161123 18:02:16-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161123 18:03:08-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161123 18:03:24< celmin|sleep> vultraz, JyrkiVesterinen: Lexical casting to Uint8 probably just takes the first character of the string and uses its ASCII value as the number.
20161123 18:03:45< celmin|sleep> Remember, streams consider 8-byte integers to represent characters, not numbers.
20161123 18:04:52< JyrkiVesterinen> Ah. That explains it. Thanks.
20161123 18:05:43< vultraz> I see...
20161123 18:07:38< celmin|sleep> vultraz, gfgtdf: Just for the record, register_widget_definition is totally out of scope for the Lua GUI2 stuff I was thinking about; however it does sound like a good idea. I'll comment on the bug report as well.
20161123 18:08:48< celmin|sleep> zookeeper: Worth adding SUF upkeep=?
20161123 18:11:01-!- celmin|sleep is now known as celticminstrel
20161123 18:11:35< gfgtdf> celticminstrel: what is it that aou were thinking about ?
20161123 18:12:11< celticminstrel> gfgtdf: Replacement for all the routines for manipulating an active dialog.
20161123 18:12:38< celticminstrel> Instead of functions in "wesnoth" you'd have methods in a userdata passed to the pre_show / post_show.
20161123 18:13:33< gfgtdf> celticminstrel: and have the userdata passed t all callback functiosn aswell ?
20161123 18:13:48< gfgtdf> to*
20161123 18:13:57< celticminstrel> Yes? I thought I just said that.
20161123 18:14:17< gfgtdf> celticminstrel: i mean callback function lik the ones pased to wesnoth.set_dialog_callback
20161123 18:14:23< celticminstrel> Oh.
20161123 18:14:30< celticminstrel> I'm not sure.
20161123 18:14:35< celticminstrel> But likely, yes.
20161123 18:15:00< celticminstrel> On the C++ side every callback receives a window, after all...
20161123 18:15:01< zookeeper> celticminstrel, it wouldn't hurt to add it, no.
20161123 18:15:20< gfgtdf> celticminstrel: on the other hand you usually define the in preshow so they could just have that userdata as an upvalue.
20161123 18:15:52< celticminstrel> Yeah, that happens a lot on the C++ side too, IIRC.
20161123 18:16:23< celticminstrel> The callbacks would be passed something, for sure. It may be a userdata representing the dialog or just one representing the widget.
20161123 18:16:37< gfgtdf> celticminstrel: when handlig upkeep in SUF, how do you inted to handle free/loyal ?, in partucular will upkeep=free also matc for unit tht have upkeep=loyal ?
20161123 18:16:53< gfgtdf> match for a unit  that*
20161123 18:17:13< celticminstrel> I'd certainly consider free, loyal, and 0 to be equivalent if I added it.
20161123 18:17:28< gfgtdf> celticminstrel: ok
20161123 18:31:34< zookeeper> that sounds reasonable
20161123 18:46:00-!- Duthlet [~Duthlet@dslb-146-060-035-062.146.060.pools.vodafone-ip.de] has quit [Quit: leaving]
20161123 18:52:48< aeth> oh, btw, I've changed my stance on recommending 3.3. 3.2 should be used unless more features are actually needed because 3.2's the one that introduces core profile. So GLSL shaders 150 core
20161123 18:53:16< aeth> s/3.3/OpenGL 3.3/
20161123 18:53:54< celticminstrel> At first I thought you were talking about Lua. Then I say "core profile" and "GLSL".
20161123 18:55:20-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161123 18:55:20-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161123 18:56:01< aeth> Lua needs a core profile too
20161123 18:56:02< aeth> :-p
20161123 18:56:09< celticminstrel> ^saw
20161123 18:57:09< aeth> so... yeah... anyway... I guess whenever 1.14 hits I'll try to see what I can do with an OpenGL 3.2 branch
20161123 18:57:10< celticminstrel> My computer should support 3.2 IIRC, but I'm not sure if the graphics card does. I suspect not though.
20161123 18:57:24< celticminstrel> (And it's now next to impossible to upgrade the graphics card.)
20161123 18:57:48< aeth> The key word is "try". Iirc, Wesnoth is spaghetti. :-p
20161123 18:58:07< celticminstrel> (Even if I could, there's only one or two cards that can actually work, both of which would be considered old.)
20161123 18:58:17< aeth> I suspect it won't work because just about everything will have to be touched in order to make the renderer work as it should... because that's how spaghetti engines work
20161123 18:58:19< celticminstrel> Heh.
20161123 18:58:58< celticminstrel> The rendering is definitely somewhat decoupled from the logic, but... probab'y not entirely.
20161123 18:59:02< celticminstrel> ^probably
20161123 19:00:55< aeth> I expect at least 6 files touched for every change
20161123 19:01:01< aeth> oh wait, it's C++ so 12 ;-)
20161123 19:01:10< aeth> </header file joke>
20161123 19:01:12< celticminstrel> Haha....
20161123 19:01:38< celticminstrel> Well, it's not like it's always pairs.
20161123 19:02:00< celticminstrel> Some headers have no source. Some sources have two matching headers (a .hpp and a _private.hpp).
20161123 19:12:41-!- louis94 [~~louis94@91.178.240.137] has joined #wesnoth-dev
20161123 19:17:33-!- prkc [~prkc@46.166.190.187] has joined #wesnoth-dev
20161123 19:42:10-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161123 19:53:54-!- mjs-de [~mjs-de@x4db539fe.dyn.telefonica.de] has joined #wesnoth-dev
20161123 19:56:39-!- astrelyon [~astrelyon@dh207-127-221.xnet.hr] has quit [Quit: WeeChat 1.4]
20161123 20:01:20-!- louis94 [~~louis94@91.178.240.137] has quit [Quit: Konversation terminated!]
20161123 20:02:56-!- JyrkiVesterinen [~JyrkiVest@89-166-117-85.bb.dnainternet.fi] has quit [Quit: .]
20161123 20:06:06-!- louis94 [~~louis94@91.178.240.137] has joined #wesnoth-dev
20161123 20:13:17< vultraz> team.hpp causes too much damn stuff to rebuild :|
20161123 20:15:25< vultraz> probably because it's in display.hpp
20161123 20:17:25-!- vultraz is now known as Inquisition
20161123 20:17:41-!- Inquisition is now known as vultraz
20161123 20:17:53-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20161123 20:17:53-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161123 20:28:59< Aginor> vultraz: nice
20161123 20:29:19< vultraz> Aginor: I have other color function-related commits coming
20161123 20:29:33< vultraz> cleaning up old gui1 cruft, renaming some stuff
20161123 20:30:27< vultraz> anyway, I've decided SDL_Color is rather simpler to handle than unit32
20161123 20:30:34< vultraz> any objection?
20161123 20:31:06< vultraz> (ie, I'm going to be seeing if more stuff can use SDL_Color vs unit32)
20161123 20:31:08< Aginor> not at all, I was suggesting it myself
20161123 20:31:29< vultraz> :D
20161123 20:31:39< Aginor> however, I would suggest wrapping sdl_color in a class of our own instead of relying on the raw sdl type
20161123 20:31:56< vultraz> oh?
20161123 20:32:07< Aginor> that seems to be how it's done for everything but rectangles, so we should stick with that convention
20161123 20:32:37< vultraz> hmm
20161123 20:32:46< vultraz> not there yet but ill keep it in mind
20161123 20:32:58< Aginor> it also allows us to add convenience functions for having *a* colour and then either turning it into an ARGB8888 for those parts of the code, and an RGBA8888 for pango
20161123 20:32:58< vultraz> might be good to give the wrapper class conversion functions
20161123 20:33:37< Aginor> that way we have an unambigious way to express a colour that can be turned into the appropriate functions for the other systems
20161123 20:34:03< vultraz> hmmm
20161123 20:36:28-!- irker215 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161123 20:36:28< irker215> wesnoth: Charles Dang wesnoth:master f197fe58420b / src/ (color_range.cpp color_range.hpp team.cpp team.hpp): Removed the GUI1 formatting rgb2highlight and its last use (team::get_side_highl https://github.com/wesnoth/wesnoth/commit/f197fe58420b1875358c7eb3c4ffd209be0d88cc
20161123 20:36:28< irker215> wesnoth: Charles Dang wesnoth:master 4128802bee08 / src/ (color_range.cpp color_range.hpp): Removed color_range::index() (unused) https://github.com/wesnoth/wesnoth/commit/4128802bee089d26aa953de539879125ecffbbac
20161123 20:36:28< irker215> wesnoth: Charles Dang wesnoth:master d7ef1ed34065 / src/ (font/text_formatting.cpp font/text_formatting.hpp team.cpp): Renamed rgb2highlight_pango to something more descriptive https://github.com/wesnoth/wesnoth/commit/d7ef1ed34065ae2fd2e46d41d3057544959a4406
20161123 20:36:40< vultraz> will do more later
20161123 20:37:04< Aginor> I'd still push for introducing that colour class now instead of later
20161123 20:37:40< Aginor> if we're making the changes, let's make it as good as we can from the start
20161123 20:39:09 * Aginor disappears for a while
20161123 20:40:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161123 20:40:22< vultraz> should be simple enough to write
20161123 20:40:31< vultraz> id probably keep the interface the same as SDL_Color
20161123 20:40:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 20:45:02< celticminstrel> vultraz: Seems to me that display.hpp shouldn't include team.hpp. Maybe consider a little refactoring?
20161123 20:45:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161123 20:45:34< celticminstrel> vultraz: Personally I'd prefer calling the components red,green,blue,alpha rather than r,g,b,a.
20161123 20:46:12< celticminstrel> Though it's not too terrible a use of single-letter names.
20161123 20:48:07< zookeeper> it's really fortunate that red,green,blue all start with a different letter in english
20161123 20:48:19< celticminstrel> Yes indeed.
20161123 20:48:23< zookeeper> people would have needed to adopt two-letter (or more!) shorthands otherwise
20161123 20:48:50< celticminstrel> Some languages don't even have a separate word for green and blue IIRC
20161123 20:49:19< zookeeper> O.o
20161123 20:49:43< matthiaskrgr> :o which one?
20161123 20:49:50< celticminstrel> Some also don't have separate words for red and yellow IIRC.
20161123 20:50:07< celticminstrel> matthiaskrgr: https://en.wiktionary.org/wiki/%E9%9D%92%E3%81%84#Japanese
20161123 20:50:45< celticminstrel> (There might be better examples, mind you.)
20161123 20:51:20< vultraz> those aren't nouns...
20161123 20:51:21< vultraz> :|
20161123 20:51:30< celticminstrel> What are you talking about?
20161123 20:51:39< vultraz> adjectives
20161123 20:51:48< celticminstrel> Why would they be nouns?
20161123 20:52:04< vultraz> because we're talking about nouns for colors?
20161123 20:52:13< celticminstrel> No we aren't?
20161123 20:52:17< vultraz> and im pointing out that you're talking about adjectives being the same in japanese
20161123 20:52:18< matthiaskrgr> when I use google translate and translate "{green,blue} color" en->jp,  I get different things
20161123 20:52:24< celticminstrel> red, green, blue are adjectives.
20161123 20:52:44< celticminstrel> matthiaskrgr: Yeah, I noticed that too; it's still the case that "aoi" can mean either green or blue, though.
20161123 20:53:05< DeFender1031> i dunno, I love nouning verby adjectives.
20161123 20:53:06< vultraz> yes they're adjectives
20161123 20:53:10< vultraz> but also nouns :/
20161123 20:53:21 * celticminstrel just found one that does get the same translation in Google.
20161123 20:53:27< vultraz> (and for the record, midori is Japanese for green)
20161123 20:53:30< celticminstrel> https://en.wiktionary.org/wiki/luhlaza
20161123 20:53:40< celticminstrel> vultraz: That's an inaccurate statement.
20161123 20:53:46< vultraz> ...what
20161123 20:54:06< celticminstrel> You can't say "green = midori" because sometimes "green = aoi" instead,
20161123 20:54:34< vultraz> as an adjective!
20161123 20:54:44< zookeeper> gfgtdf, when the [on_undo]/[on_redo] actions are triggered, where should the undoing/redoing unit be at that time? because i'm seeing some weird behavior: https://paste.ee/p/6lB2J
20161123 20:54:53< celticminstrel> Uh, vultraz, colours are adjectives.
20161123 20:55:08< celticminstrel> They're fundamentally adjectives.
20161123 20:55:28< zookeeper> gfgtdf, the variable substitution for $x1,$y1,$x2,$y2 works right in the [on_undo]/[on_redo] blocks, but the unit doesn't get stored
20161123 20:55:40< vultraz> im pretty sure they're also grammatically nouns... :/
20161123 20:55:44< celticminstrel> Sure they can function as nouns, but that's true of many other adjectives too.
20161123 20:55:47< zookeeper> gfgtdf, and i can only guess that that's because the unit isn't really yet at that location
20161123 20:56:21< celticminstrel> (Mind you, aren't they grammatically verbs in Japanese? Or maybe that was Chinese.)
20161123 20:56:31< vultraz> when I say midori im referring to the color green. you can say aoi if you mean someone looks green as in queasy.
20161123 20:56:43< vultraz> (im guessing, since ive never heard that usage)
20161123 20:57:57< vultraz> (in japanese)
20161123 20:58:18< celticminstrel> Or if referring to the colour of the leaves of trees IIUC.
20161123 20:58:46< vultraz> pretty sure one would use midori
20161123 20:59:31< celticminstrel> I assume Wiktionary makes that claim for a reason.
20161123 21:00:09< celticminstrel> Looks like "midori" in Japanese is the same as "orange" in English, etymologically speaking.
20161123 21:00:47< celticminstrel> So, it's a newer word for the colour.
20161123 21:04:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161123 21:04:40< celticminstrel> zookeeper: The undoing/redoing unit may not be at $x1,$y1 in the [on_undo] for a moveto - IIRC it's moved back to its original position before the [on_undo] is fired.
20161123 21:05:21< celticminstrel> (What's $x2,$y2 in a moveto? The source location?)
20161123 21:05:42< celticminstrel> But... hmm...
20161123 21:05:58< zookeeper> when i try to store both the x1,y1 unit and x2,y2 unit, the unit stored is from x1,y1 unit. so if you do a store/unstore in an [on_undo], the unit is duplicated.
20161123 21:05:59< celticminstrel> Was that what it was, or was it $unit.x,$unit.y that are wrong in the undo/redo...
20161123 21:06:42< zookeeper> _however_, even though the unit gets stored, i can't output its name in a message? -.-
20161123 21:07:15< celticminstrel> Well, you don't have delayed variable substitution enabled, so try $|foo.name
20161123 21:07:27 * zookeeper facepalms
20161123 21:07:30< zookeeper> oh yeah
20161123 21:07:57< zookeeper> that would certainly make sense to do :>
20161123 21:09:28< zookeeper> ok so i think that explains the problem. it seems weird that the position of the unit is updated after [on_undo] though, but maybe that's how it was intended for some technical reason, i don't recall.
20161123 21:10:26< celticminstrel> Well, for that you'd have to ask gfgtdf. I only implemented delayed_variable_substitution and reapplying the stored variables.
20161123 21:11:29< zookeeper> if i move to 15,17, then during both undo and redo the unit is at 15,17
20161123 21:11:48< celticminstrel> Based on $unit.x,$unit.y, right?
20161123 21:11:55< zookeeper> no
20161123 21:12:01< celticminstrel> Based on $x1,$y1?
20161123 21:12:18< zookeeper> based on from which location a unit was successfully stored
20161123 21:13:31-!- mjs-de [~mjs-de@x4db539fe.dyn.telefonica.de] has quit [Remote host closed the connection]
20161123 21:13:53< zookeeper> i was pretty sure i tested this stuff pretty closely when it was added...
20161123 21:14:19< zookeeper> dunno if something like that could have subtly broken since then, or whether i just missed it originally
20161123 21:16:06-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has joined #wesnoth-dev
20161123 21:16:18< celticminstrel> I think it was like that when I implemented reapplying the stored variables for delayed variable substitution.
20161123 21:16:38< celticminstrel> At least, there was some issue about getting the unit stored.
20161123 21:17:19< zookeeper> hmh. well, it seems like a bug to me but gfgtdf ought to know.
20161123 21:17:46< zookeeper> when undoing, the unit visually moves to the original location, then [on_undo] triggers but the unit still exists at the moveto location
20161123 21:18:58< zookeeper> x1,y1,x2,y2 and all that seems to be set correctly, it's only the unit which exists in the wrong place at that point in time
20161123 21:19:24< celticminstrel> I imagine it's probably fixable. Note that anyone fixing it must also pay attention to the reapplication of stored variables when the on_undo/on_redo is fired.
20161123 21:22:11< zookeeper> i guess for now i'll workaround by storing based on id...
20161123 21:30:05-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has quit [Ping timeout: 260 seconds]
20161123 21:31:20< zookeeper> oh, wait, no that won't fix it either.
20161123 21:31:42< celticminstrel> Just don't use $unit.x or $unit.y?
20161123 21:32:06< zookeeper> would have to rewrite a lot
20161123 21:32:19< zookeeper> how sure are you that your big commit didn't cause this? :P
20161123 21:32:46< celticminstrel> My big commit?
20161123 21:33:02< zookeeper> yes, the thing you added
20161123 21:33:18< celticminstrel> Reapplying the stored variables?
20161123 21:33:28< zookeeper> yes, the commit in which you did that
20161123 21:33:47< celticminstrel> If I recall correctly, in that commit I had to correct for the problem...
20161123 21:34:11< celticminstrel> I don't think I can be completely sure that it didn't cause it though.
20161123 21:34:18-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 268 seconds]
20161123 21:35:29< zookeeper> if you're unsure and it's inconvenient to test so far back, i can download 1.13.4 and test with that
20161123 21:36:04< celticminstrel> Was it 1.13.5 that that commit was in? I don't remember.
20161123 21:36:13< celticminstrel> But feel free to do that.
20161123 21:36:16< zookeeper> yes
20161123 21:36:48-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20161123 21:45:35< gfgtdf> zookeeper: not sure whethre the unit during [on_undo] i'd just identify the unit b id indtead of by location
20161123 21:45:59< gfgtdf> zookeeper: like [filter] id = $unit.id [/filter]
20161123 21:46:29< zookeeper> sure, but in my particular case i first need to store the unit (in which i can use id, sure) and then call a separate event which does stuff to the unit based on its location
20161123 21:47:06< zookeeper> except, that other event thinks the unit is somewhere it really isn't going to be, and thus everything breaks
20161123 21:47:27< gfgtdf> zookeeper: well thn you coudl just use the location of unit that you just stored?
20161123 21:47:35-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161123 21:47:39< celticminstrel> Does the separate event work on the stored unit?
20161123 21:47:42< zookeeper> gfgtdf, that's the point; the location is wrong
20161123 21:47:52< celticminstrel> Or does it re-store it based on the ID or something?
20161123 21:48:00-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 260 seconds]
20161123 21:48:12< celticminstrel> If it's using the unit you just stored, you could eg {VARIABLE foo.x $x1} etc
20161123 21:48:35< celticminstrel> (Obviously a workaround, but still.)
20161123 21:48:55< zookeeper> i move from 15,17 to 16,18. then i undo, and when [on_undo] happens, the unit is still in 16,18.
20161123 21:50:06< gfgtdf> zookeeper: not sure if i understand, what exactly is the code that currnely fails ?
20161123 21:50:37< zookeeper> a-ha! in 1.13.4 it works correctly
20161123 21:51:43< zookeeper> gfgtdf, well i can write another simple testcase for you if you want. unless celticminstrel feels implicated and wants to investigate :P
20161123 21:54:25-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20161123 21:57:42< zookeeper> https://paste.ee/p/9cI6s
20161123 21:57:46< gfgtdf> zookeeper: hmm no i think if it realyl works on 1.13.4 then its quite likeley inrodiced by the delayevaraiblesubtution patch.
20161123 21:58:15< zookeeper> you get correct output in 1.13.4, wrong output on undo (but correct on redo) in master
20161123 21:59:54-!- prkc [~prkc@46.166.190.187] has quit [Quit: Leaving]
20161123 21:59:57< gfgtdf> zookeeper: there seems to be some strnage suff going on in master in undo_action.cpp::execute_event that resets the unit location
20161123 22:00:15< gfgtdf> zookeeper: try removign this line https://github.com/wesnoth/wesnoth/blob/master/src/actions/undo_action.cpp#L99
20161123 22:04:12< zookeeper> it wanted to start recompiling all sorts of things now, dunno how long this will take
20161123 22:05:02-!- travis-ci [~travis-ci@ec2-54-226-182-183.compute-1.amazonaws.com] has joined #wesnoth-dev
20161123 22:05:03< travis-ci> wesnoth/wesnoth#12146 (master - d7ef1ed : Charles Dang): The build is still failing.
20161123 22:05:03< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/178413585
20161123 22:05:03-!- travis-ci [~travis-ci@ec2-54-226-182-183.compute-1.amazonaws.com] has left #wesnoth-dev []
20161123 22:07:08< zookeeper> gfgtdf, yes that seems to have worked
20161123 22:07:36< celticminstrel> If that line is being removed, should line 104 be removed too?
20161123 22:07:47< celticminstrel> And does removing them create different problems?
20161123 22:08:15< gfgtdf> celticminstrel: yes 104 shodul be rmeoved too (and the code that 'reverts' those changes at the end aswell)
20161123 22:08:20< celticminstrel> For example, maybe with them it works in redo but not undo, and without it works in undo and not redo?
20161123 22:08:46< celticminstrel> So lines 114-121 as well.
20161123 22:09:02< gfgtdf> celticminstrel: iirc you added those so maybe you know why they were added.
20161123 22:09:42< celticminstrel> I don't remember, unfortunately.
20161123 22:09:50< celticminstrel> I assume there was a reason though.
20161123 22:11:27-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161123 22:12:25< gfgtdf> celticminstrel, zookeeper : you wnat to commit those changes, or shodul i do it ?
20161123 22:12:25< zookeeper> 104 and 114-121?
20161123 22:12:27 * zookeeper tries
20161123 22:13:12< gfgtdf> zookeeper: the real1m real2 local vaiales can likeley be rmeoved aswell since they are the unused
20161123 22:14:37 * zookeeper blinks
20161123 22:14:49< zookeeper> the unit seems to be in two places at once now... in some circumstances
20161123 22:15:11< gfgtdf> zookeeper: after you rmeoved those lines ?
20161123 22:15:17< zookeeper> yes
20161123 22:15:24< gfgtdf> zookeeper: whta exactly do you mean ?
20161123 22:15:28< zookeeper> whoops, WML mistake
20161123 22:15:35< zookeeper> x,y=$x2,$2 :p
20161123 22:15:58< celticminstrel> So does it work without them both on undo and on redo?
20161123 22:16:39< zookeeper> yeah everything seems to work right now, with all the abovementioned lines removed
20161123 22:16:52< celticminstrel> Huh... wonder why I had that code there then...
20161123 22:17:04< celticminstrel> gfgtdf: Feel free to commit it.
20161123 22:17:23< celticminstrel> We can always revert (partially or fully) if the original reason for it resurfaces and is shown to be valid.
20161123 22:17:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161123 22:17:58< celticminstrel> If you're committing from github and want to remove real1,real2, don't forget to remove where it's assigned as well.
20161123 22:19:57< gfgtdf> celticminstrel: that code has 2 scopedxy unit both going to variable "unit"
20161123 22:20:24< gfgtdf> scopedxy units*
20161123 22:20:28< celticminstrel> Oops?
20161123 22:20:37< celticminstrel> Obviously one should be second_unit.
20161123 22:20:58< celticminstrel> I wonder if that was the true cause of zookeeper's problem then...
20161123 22:21:35< celticminstrel> ...no, I guess probably not. It wouldn't've manifested in a moveto because there's only one unit.
20161123 22:24:18< irker215> wesnoth: gfgtdf wesnoth:master d11974ccc5e1 / src/actions/undo_action.cpp: fix unit having wrong locations in on undo/redo handler https://github.com/wesnoth/wesnoth/commit/d11974ccc5e19aa68b845ff0dbc281e82820d91a
20161123 22:25:37< celticminstrel> Wait, what if you use delayed_variable_substitution=yes...
20161123 22:26:22< celticminstrel> Does the test work with that too, or only without it?
20161123 22:27:09< gfgtdf> celticminstrel: which test ?
20161123 22:27:28< celticminstrel> zookeeper's pastebin
20161123 22:27:38< celticminstrel> (Maybe that pastebin could be made into a unit test?)
20161123 22:28:53< zookeeper> celticminstrel, i can test, but what values should i expect x1,y1,x2,y2 to hold during on_undo/on_redo?
20161123 22:29:35< celticminstrel> Pretty sure they should hold the same values as the did in the original event. Also, $unit.x and $unit.y should ideally be set correctly too.
20161123 22:30:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161123 22:33:09< zookeeper> mmkay, compiling again
20161123 22:33:16< zookeeper> i guess in the meanwhile i can throw in a $unit test
20161123 22:40:07< gfgtdf> from looking at the code i wonder wheterh [on_undo] wokr correctly at wml menu items, since i cannot see any execute_undo_umc_wml in undo_dummy_action 
20161123 22:42:12< celticminstrel> Is it supposed to work with WML menu items?
20161123 22:43:18< gfgtdf> celticminstrel: i don't see why not.
20161123 23:09:05< zookeeper> well, i won't test that thing right now because menu_events.obj : error LNK2001: unresolved external symbol "public: __thiscall gui2::dialogs::terrain_layers::terrain_layers(class display &,struct map_location const &)" (??0terrain_layers@dialogs@gui2@@QAE@AAVdisplay@@ABUmap_location@@@Z)
20161123 23:09:22< zookeeper> probably just need to add something somewhere but no time for that tonight
20161123 23:12:32< gfgtdf> zookeeper: looks liek something missing in your projectfiels
20161123 23:12:44< zookeeper> yep, the files vultraz added
20161123 23:12:49< zookeeper> easy enough to fix, but not now
20161123 23:12:57-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161123 23:23:23-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds]
20161123 23:32:39-!- RatArmy [~RatArmy@om126161112076.8.openmobile.ne.jp] has joined #wesnoth-dev
20161123 23:45:18-!- travis-ci [~travis-ci@ec2-54-226-182-183.compute-1.amazonaws.com] has joined #wesnoth-dev
20161123 23:45:19< travis-ci> wesnoth/wesnoth#12147 (master - d11974c : gfgtdf): The build is still failing.
20161123 23:45:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/178444098
20161123 23:45:19-!- travis-ci [~travis-ci@ec2-54-226-182-183.compute-1.amazonaws.com] has left #wesnoth-dev []
--- Log closed Thu Nov 24 00:00:45 2016