--- Log opened Wed Nov 29 00:00:37 2017
20171129 00:01:29< irker560> wesnoth: Gregory A Lundberg wesnoth:master 4dbe4fbbb24b / src/ (font/text.cpp serialization/string_view.hpp): Eliminate use of string_view::at https://github.com/wesnoth/wesnoth/commit/4dbe4fbbb24b0e3546e6afd1c4bcc012cb431942
20171129 00:03:50-!- Bonobo [~Bonobo@220-244-175-160.static.tpgi.com.au] has quit [Ping timeout: 268 seconds]
20171129 00:04:41-!- Bonobo [~Bonobo@203.63.76.34] has joined #wesnoth-dev
20171129 00:14:09-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20171129 00:14:09< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release Alexander van Gessel 383f81c: Change code style Failed
20171129 00:14:09< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-756
20171129 00:14:13-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20171129 00:17:22-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20171129 00:26:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20171129 00:26:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 00:27:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20171129 00:27:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 00:31:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20171129 00:43:05-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20171129 00:43:05< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug Alexander van Gessel 383f81c: Change code style Failed
20171129 00:43:05< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-756
20171129 00:43:09-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20171129 00:52:50-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20171129 00:52:51< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release Alexander van Gessel 383f81c: Change code style Failed
20171129 00:52:51< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-762
20171129 00:52:54-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20171129 01:00:25-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20171129 01:00:26< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug Alexander van Gessel 383f81c: Change code style Failed
20171129 01:00:26< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-762
20171129 01:00:29-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20171129 01:04:05-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Quit: Leaving]
20171129 01:33:50-!- doggone [~doggone@unaffiliated/doggone] has left #wesnoth-dev ["Leaving"]
20171129 01:36:09-!- shiki [~Shiki@p54856D2C.dip0.t-ipconnect.de] has quit [Quit: Verlassend]
20171129 02:01:48-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20171129 02:01:55-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20171129 02:07:48-!- timotei__ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20171129 02:10:27-!- timotei_ [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 240 seconds]
20171129 02:38:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20171129 02:38:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20171129 03:02:04-!- irker560 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20171129 03:16:24-!- irker849 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20171129 03:16:24< irker849> wesnoth: Gregory A Lundberg wesnoth:master 11d7b9f0cfe2 / join.lua: Fix mp_tests https://github.com/wesnoth/wesnoth/commit/11d7b9f0cfe29ab6d6b5829c8e337b7cb67eeb18
20171129 04:21:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 04:26:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20171129 04:30:51-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20171129 05:10:27-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20171129 06:10:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 06:14:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20171129 06:41:57-!- TadCarlucci [~lundberg@74.193.219.119] has quit [Ping timeout: 240 seconds]
20171129 06:46:36-!- TadCarlucci [~lundberg@74.193.219.119] has joined #wesnoth-dev
20171129 06:56:01-!- TadCarlucci [~lundberg@74.193.219.119] has quit [Read error: Connection reset by peer]
20171129 06:56:21-!- TadCarlucci [~lundberg@74.193.219.119] has joined #wesnoth-dev
20171129 07:35:03-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20171129 07:36:31-!- fabi [~fabi@2a02:810c:c840:2e65:35fd:7e23:f5ca:3a8d] has joined #wesnoth-dev
20171129 07:36:31-!- fabi [~fabi@2a02:810c:c840:2e65:35fd:7e23:f5ca:3a8d] has quit [Changing host]
20171129 07:36:31-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20171129 07:58:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 08:03:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20171129 08:08:30-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20171129 09:06:34-!- vladimirslavik [vslavik@nat/redhat/x-mrzcjyhkkrfiixnd] has joined #wesnoth-dev
20171129 09:10:23-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20171129 09:46:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 09:51:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20171129 10:37:26-!- kallaballa [~amir@194-166-158-138.hdsl.highway.telekom.at] has joined #wesnoth-dev
20171129 10:39:11-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20171129 11:35:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 11:39:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20171129 11:44:59-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20171129 11:48:10-!- irker849 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20171129 11:50:14-!- kallaballa [~amir@194-166-158-138.hdsl.highway.telekom.at] has quit [Ping timeout: 255 seconds]
20171129 13:00:51-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20171129 13:28:20-!- kallaballa [~amir@194-166-158-138.hdsl.highway.telekom.at] has joined #wesnoth-dev
20171129 14:10:42< vn971> I wonder, can I use `ipairs` over `wesnoth.sides` or cannot I? https://wiki.wesnoth.org/LuaWML:Sides#wesnoth.sides
20171129 14:10:42< vn971> If I understand it correctly, there can be "gaps" in side numbers. At the same time, wiki says that the table above is "a table indexed by side numbers". If it's indexed by side numbers, then this table can also have gaps. This means that `ipairs` will not work on `wesnoth.sides`.
20171129 14:11:08< vn971> Lua example: t={[1] = 1, [3] = 3};  for k,v in ipairs(t) do print(k,v) end;  -- prints only "1", but never "3"
20171129 14:11:54< vn971> also, I'd call indexing by side numbers counter-intuitive: better return a normal Lua _array_ instead of a table that looks like an array, but isn't.
20171129 14:14:03< vn971> wesnoth built-in lua files seem to use consequent indices, which probably means that the wiki is incorrect. If it's so, I'd fix the wiki.
20171129 14:14:20< vn971> * seem to use consequent indices to access `wesnoth.sides`
20171129 14:14:27< TadCarlucci> vn971 Considering the only data structure is "table" I don't get the comment about (non-existent) Lua arrays
20171129 14:16:11< vn971> TadCarlucci: Are keys consequent integers starting from 1 or aren't they? That's the question. In the second case, you can use `ipairs`. Which, in wesnoth case, has an additional benefit in that it avoids OOS in traversal randomness. (See https://wiki.wesnoth.org/LuaWML#Random_Lua_table_iteration )
20171129 14:17:13-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20171129 14:19:43< TadCarlucci> Side numbers are what the UMC author decides. If the author wants to use side numbers 101, 325 and 62 that's fine. Yes, that means ipairs won't work. So use the keys and if you're worried that side "PLUGH" exists check they're numeric.
20171129 14:21:19< TadCarlucci> I don't see any issue with the examples in your linked web page.
20171129 14:21:42< vn971> TadCarlucci: well, I know that side numbers are arbitrary. The question is whether `wesnoth.sides` keys are arbitrary. Whether they're consequent (to have array-like methods work on them), or equal to `side.side`.
20171129 14:23:06< vn971> Also, if keys are not consequent, some wesnoth built-in methods are incorrect. For example, `helper.get_sides`.
20171129 14:23:48< vn971> it relies on the fact that `wesnoth.sides` keys are consequent numbers starting from 1.
20171129 14:23:53< TadCarlucci> IIRC from wokr with someone else a few days ago, I think the entries in wesnoth.sides are: for a given I, wesnoth.sides[I].side == I 
20171129 14:24:26< vn971> TadCarlucci: that would be very bad. (See above for example, why.)
20171129 14:24:56< vn971> Can someone confirm from the code that it's the case? If it's currently not the case, I'd change the API until it's too late.
20171129 14:26:52< TadCarlucci> Seems to me all that's needed is a warning on the section about wesnoth.sides that you can't relably use ipairs unless your UMC ensures side numbers are sequential, starting from 1, with no skips.
20171129 14:27:57< TadCarlucci> Otherwise, just get the keys and ipairs that and use the results to index wesnoth.sides
20171129 14:28:00< vn971> TadCarlucci: needed for what? The API is insane that way. It's much, much more sane to use "arrays" (consequent integers as keys).
20171129 14:29:51< TadCarlucci> Well, it seems to me that's an argument which should have been made back in 2003.
20171129 14:31:31< vn971> Anyway, my question is: what is the current implementation? I rather suspect that it's still "sane", because otherwise many built-in usages are incorrect.
20171129 14:37:52< vn971> Also, later the wiki says: wesnoth.message(string.format("%d sides", #wesnoth.sides))    Now, you can't really use #wesnoth.sides  if keys are not consequent integers.
20171129 14:37:52< vn971> I think the whole problem is as simple as: update the wiki and say that wesnoth.sides returns an "array".
20171129 14:37:58< TadCarlucci> In many respects, Wesnoth is fragile. It would not surprise me at all if everyone just happened to use sides 1, 2, 3 ... and nobody's every notices that some Lua scripts fail is you use sides 1, 3, 5, ... instead. Seems to me it would be a lot quicker to do a test scenario and check than to try to find it in the C++
20171129 14:38:54< vultraz> there used to be a requirement that side numbers be consecutive
20171129 14:38:55< vn971> TadCarlucci: y, you may be right about a test scenario. IDK how to hack into "side numbers" though.
20171129 14:38:57< vultraz> prior to 1.13
20171129 14:39:11< vultraz> IIRC in 1.13 that was lifted and everything internally now "just works"
20171129 14:39:26< TadCarlucci> Define sides 1, 3, 5 and see what you get from ipairs
20171129 14:39:27< vn971> vultraz: that means a lot of built-in code is now broken.
20171129 14:39:37< vultraz> excuse me?
20171129 14:39:39< vn971> TadCarlucci: IDK how to define that.
20171129 14:40:10< TadCarlucci> This is Wesnoth "working but actually broken" is always the state we're in
20171129 14:41:22< vn971> vultraz:  grep -R '#wesnoth.sides' /share/wesnoth/data/lua   Also, most of other usages of `weshot.sides` would be incorrect, too. `helper.get_sides` would be the most obvious example.
20171129 14:41:42< vn971> TadCarlucci: nah-nah-nah, let's try to fix it where we can.:PP
20171129 14:41:56< TadCarlucci> vn971 If you cannot create a test scenarion with sides 1, 3 and 5 but no 2 or 4 then you're worrying about a non-issue.
20171129 14:42:11< vn971> Can we make `wesnoth.sides` return an "array" at least? That would fix a lot of problems already.
20171129 14:42:14< vultraz> not necessarily 
20171129 14:42:34< Ravana_> >When defining sides, they must be defined in order since the side number is checked against the number of sides seen so far.
20171129 14:42:44< TadCarlucci> vn971 It's Whack-a-Mole. Come up with a test where we have a Mole to Whack and we're all over it
20171129 14:43:23< TadCarlucci> Ravana_, So the issue is a non-issue. WML checks, ipairs will work. Kumbaya
20171129 14:43:43< vultraz> oh, whatever
20171129 14:44:26< vn971> Ravana_: where were you quoting from?
20171129 14:44:38< Ravana_> https://wiki.wesnoth.org/SideWML
20171129 14:45:20< vn971> Ravana_: well, that means that we _can_ define sides 1,100,100000
20171129 14:45:34< vn971> non-consequent I mean.
20171129 14:45:39< vn971> (and thanks.)
20171129 14:46:06< Ravana_> >the side number is checked against the number of sides seen so far
20171129 14:46:25< Ravana_> from that I expect message if they are not as expected
20171129 14:46:34< vn971> Ravana_: yes. And? 100 is not equal to 1, so we can add it. 100000 is not equal to 100 and 1, so we can add it.
20171129 14:46:50< TadCarlucci> I read that as "count the number of sides, the new side number must be equal to that, plus one, or WML will complain"
20171129 14:47:05< vn971> I think equality is meant by "checking against".
20171129 14:47:31< vn971> > The server doesn't limit the number of sides anymore
20171129 14:47:55< vultraz> That's a completely different thing
20171129 14:47:59< vultraz> don't confuse it
20171129 14:53:16< vn971> I'm really confused. Does wesnoth.sides return an "array" or doesn't it?...
20171129 14:53:48< vn971> or "nobody knows, let's do something else" xD
20171129 14:55:11< vultraz> Why don't you just test and see
20171129 14:55:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171129 14:56:37< vn971> vultraz: I tried, but when I've set sides to 1001, 1002, 1003 etc, wesnoth just loaded them as 1,2,3.
20171129 14:56:46< vultraz> then good
20171129 14:56:56< vultraz> we have no problem
20171129 14:56:58< vultraz> move on
20171129 14:57:00< vultraz> call it a day
20171129 14:59:06-!- vslavik [vslavik@nat/redhat/x-okdfnsaxskdqkbws] has joined #wesnoth-dev
20171129 14:59:33< vn971> no need to update the wiki either? https://wiki.wesnoth.org/SideWML   Well, anyway, going to use `ipairs` over `wesnoth.sides` then and hope it's OK..
20171129 15:00:08-!- vladimirslavik [vslavik@nat/redhat/x-mrzcjyhkkrfiixnd] has quit [Ping timeout: 276 seconds]
20171129 15:00:18-!- vslavik [vslavik@nat/redhat/x-okdfnsaxskdqkbws] has quit [Remote host closed the connection]
20171129 15:00:56-!- vslavik [vslavik@nat/redhat/x-hliqqzlbeyylmbne] has joined #wesnoth-dev
20171129 15:19:49-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20171129 15:23:39-!- vslavik [vslavik@nat/redhat/x-hliqqzlbeyylmbne] has quit [Read error: Connection reset by peer]
20171129 15:24:00-!- vslavik [vslavik@nat/redhat/x-kgactxtlyucpbbrb] has joined #wesnoth-dev
20171129 15:24:15-!- Bonobo [~Bonobo@203.63.76.34] has quit [Ping timeout: 248 seconds]
20171129 15:25:22-!- vslavik [vslavik@nat/redhat/x-kgactxtlyucpbbrb] has quit [Remote host closed the connection]
20171129 15:26:14-!- vslavik [vslavik@nat/redhat/x-sztjchgxtdzfoaub] has joined #wesnoth-dev
20171129 15:29:51-!- vslavik [vslavik@nat/redhat/x-sztjchgxtdzfoaub] has quit [Remote host closed the connection]
20171129 15:32:05-!- vladimirslavik [vslavik@nat/redhat/x-kaljuehkpktpcuov] has joined #wesnoth-dev
20171129 15:33:51-!- vladimirslavik [vslavik@nat/redhat/x-kaljuehkpktpcuov] has quit [Remote host closed the connection]
20171129 15:47:36 * TadCarlucci wonders why all the angst over using ipairs on a sparse array. That's what pairs is for.
20171129 15:50:56< vn971> TadCarlucci: well, simplest reason to come to my mind: https://wiki.wesnoth.org/LuaWML#Random_Lua_table_iteration
20171129 15:51:16< vn971> it's really important when writing Lua code in my experience. I have to think about it, like, all the time.
20171129 15:51:38-!- kallaballa [~amir@194-166-158-138.hdsl.highway.telekom.at] has quit [Ping timeout: 258 seconds]
20171129 15:58:00-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20171129 15:58:06< TadCarlucci> If it's important that you do things in side-number order and want to be sure you can handle sparse population, you're going to have to use pairs to build an intermediate table of side numbers and sort them. But this is all a lot of work to handle a case you won't see. It's not presently a problem. It probably will never be a problem. So it seems better to not bother future-proofing and simply fixing in the unlikely event it ever becomes a 
20171129 15:58:06< TadCarlucci> problem.
20171129 15:59:51< vn971> TadCarlucci: I don't want to do it in side-number order. I want to avoid OOS. A simple code as explained on the wiki really does create OOS. Been there, had the fun of debugging that.
20171129 16:00:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20171129 16:00:31< vn971> TadCarlucci: so it's about doing the same operations on all clients, not really caring about side numbers etc.
20171129 16:01:43< TadCarlucci> It seems you're chasing a non-issue down a rabbit hole. Yes, it's possible to code defensively to ensure it's a non-issue but that seems overkill.
20171129 16:02:15< vn971> TadCarlucci: what is a non-issue? o_O  The fact that my addon will have OOS is a non-issue? Or what exactly?
20171129 16:02:46< TadCarlucci> Worrying that ipairs over wesnoth.sides won't see all the sides.
20171129 16:03:40< TadCarlucci> If you're wanting to be sure, use pairs() save the keys, sort them, then ipairs over the sorted keys
20171129 16:04:27< vn971> ah, if you're about `wesnoth.sides` specifically, then yes, I decided to ignore that issue. I really don't like the fact that wiki is inconsistent (in my opinion), but I can't fix anything by my own so I just have to live with that.
20171129 16:07:05< TadCarlucci> Like most documentation, most places, it doesn't really document anything, it's often out-dated and sometimes just plain wrong. Although, since it's a wiki, the last two can be addressed.
20171129 16:08:00< vn971> I can't change this wiki part because I'm not sure I can make _correct_ changes. Whenever I can, I update the wiki.
20171129 16:09:10< vn971> BTW, I would rate the overall wiki quality as "very high". You can find some blind spots if you really try to, but 99% it's very descriptive, clear and correct.
20171129 16:09:55< vn971> Especially if you compare that to game-specific wikis in the wild. Or worse, some companies internal wikis.
20171129 16:10:07< vn971> company-s
20171129 16:10:56< vn971> that's from Lua addon developer perspective.
20171129 16:11:17< TadCarlucci> Seems to me, then, that what you're saying it the comment about OOS issues does not go far enough. It needs to warn that you need to ensure you always do things in the same order, and, yes, ipairs can do that. But it needs to point out that ipairs is not a complete solution and you may have to use a sort or other methods to ensure you're doing things in the same order on each client in a mutli-player game.
20171129 16:11:31-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20171129 16:12:29< vn971> TadCarlucci: well, you can update the wiki if you want to. ;-)
20171129 16:13:21< vn971> That paragraph was actually written by me, and I don't mind changes. I think. (Though I didn't really get what you're talking about, yet.)
20171129 16:14:11< vn971> pairs() was a reason of OOS for me, so I've documented the "trap".
20171129 16:15:56< TadCarlucci> It was one example of the trap. And ipairs might solve it, or might miss things.
20171129 16:17:10< vn971> TadCarlucci: can you paste an example of a code that can lead to OOS, besides `pairs` and `next` over non-array ?
20171129 16:17:36< TadCarlucci> Nope.
20171129 16:19:00< TadCarlucci> I probably could devise one. But I'd have to test it and it's all too much work.
20171129 16:27:42< vn971> * Whoray! I've just finished writing "Mirror leaders" function in Lua, that would work on any kind of Era and any kind of map. One step closer to allow any era in Creep Wars.)
20171129 16:36:35-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Ping timeout: 240 seconds]
20171129 17:04:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 17:44:25-!- sigurdfd [sigurdfd@dynamic-acs-72-23-110-196.zoominternet.net] has joined #wesnoth-dev
20171129 17:48:56-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20171129 17:50:53-!- kallaballa [~amir@public.metalab.wien.funkfeuer.at] has joined #wesnoth-dev
20171129 18:02:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20171129 18:19:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171129 18:27:27< sigurdfd> zookeeper: thoughts on the DiD pr's?
20171129 18:32:41-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20171129 18:37:20< zookeeper> sigurdfd, yeah i had a few comments, tonight seems like a good night to actually get to those...
20171129 18:38:12< sigurdfd> ok, I'll be around here for the next 4-5 hours.
20171129 18:38:47< zookeeper> great
20171129 19:34:28-!- irker525 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20171129 19:34:28< irker525> wesnoth: Jyrki Vesterinen wesnoth:master 72739c56a5d8 / utils/travis/mp_test_executor.sh: Revert ignoring MP test failures due to video init failure (2e5c5da0036be2e68b42 https://github.com/wesnoth/wesnoth/commit/72739c56a5d897c9d9ee276f5e2740ec4be39c24
20171129 19:43:24-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection]
20171129 20:29:10-!- mjs-de [~mjs-de@x4db607eb.dyn.telefonica.de] has joined #wesnoth-dev
20171129 20:30:57-!- kallaballa [~amir@public.metalab.wien.funkfeuer.at] has quit [Ping timeout: 240 seconds]
20171129 21:13:49-!- mjs-de [~mjs-de@x4db607eb.dyn.telefonica.de] has quit [Remote host closed the connection]
20171129 21:24:14< AI0867> vultraz: do you know what this commit 383f81c is that I'm getting notifications about? Appveyor points to https://github.com/wesnoth/wesnoth/commit/383f81cb2186908771976afe69f08cc2b37a41d7 but I didn't commit that
20171129 21:31:59-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev
20171129 21:32:22< zookeeper> sigurdfd, there.
20171129 21:32:41< zookeeper> (WRT #2188)
20171129 21:55:50-!- kallaballa [~amir@194-166-158-138.hdsl.highway.telekom.at] has joined #wesnoth-dev
20171129 22:11:06-!- kallaballa [~amir@194-166-158-138.hdsl.highway.telekom.at] has quit [Ping timeout: 260 seconds]
20171129 22:14:46< vultraz> AI0867: weird
20171129 22:15:06< vultraz> perhaps this is the commit that's makingall the PRs un-rebaseable
20171129 22:15:12< vultraz> I don't know what it is
20171129 22:20:25< AI0867> unrebaseable?
20171129 22:20:33< sigurdfd> vultraz: 2188 was unrebasable, then I locally rebased against current master head and pushed, and it became rebaseable again
20171129 22:21:00< vultraz> AI0867: most of the open PRs say they cannot be rebased
20171129 22:25:05< AI0867> Can't be rebased or cannot be merged at all?
20171129 22:25:18< AI0867> I just checked three, and found 2 mergable and 1 unmergable
20171129 22:25:25< irker525> wesnoth: Jeffrey 'Sigurd' Westcoat wesnoth:master 822f98b754fd / data/campaigns/Heir_To_The_Throne/scenarios/17_Scepter_of_Fire.cfg: HttT S17: Fix lava issues (#2249) https://github.com/wesnoth/wesnoth/commit/822f98b754fda5e6f8dba5a1641c8dc6be4bec77
20171129 22:26:13< vultraz> rebased
20171129 22:26:19< vultraz> we want Rebase and Merge
20171129 22:29:42< AI0867> do you have an example?
20171129 22:31:14< vultraz> https://github.com/wesnoth/wesnoth/pull/2200 https://github.com/wesnoth/wesnoth/pull/2207
20171129 22:31:47< vultraz> and your own gender PR
20171129 22:32:48< irker525> wesnoth: Gregory A Lundberg wesnoth:master bdcfe84d6f2b / data/campaigns/Descent_Into_Darkness/scenarios/01_Saving_Parthyn.cfg: DiD S01 Fix bug: Allow undo https://github.com/wesnoth/wesnoth/commit/bdcfe84d6f2b7e49f222b335e637dcc32befc338
20171129 22:32:50< irker525> wesnoth: Gregory A Lundberg wesnoth:master a6fce925859a / data/campaigns/Descent_Into_Darkness/scenarios/02_Peaceful_Valley.cfg: DiD S02 Cannot undo https://github.com/wesnoth/wesnoth/commit/a6fce925859a39a6405bb38f1507caf03096deed
20171129 22:32:52< irker525> wesnoth: Gregory A Lundberg wesnoth:master a599436ec362 / data/campaigns/Descent_Into_Darkness/scenarios/02_Peaceful_Valley.cfg: DiD Remove variable artifacts https://github.com/wesnoth/wesnoth/commit/a599436ec362d1ed79670e93aee9b0f09e63f7d8
20171129 22:32:54< irker525> wesnoth: Gregory A Lundberg wesnoth:master 128413da5a79 / data/campaigns/Descent_Into_Darkness/scenarios/02_Peaceful_Valley.cfg: DiD S02 Fix bug: Swamp only https://github.com/wesnoth/wesnoth/commit/128413da5a79a906d6aa1298e60ae6ad6429d840
20171129 22:32:56< irker525> wesnoth: Gregory A Lundberg wesnoth:master 3f646cc96547 / data/campaigns/Descent_Into_Darkness/scenarios/04_Beginning_of_the_Revenge.cfg: DiD S04 Todo: Add snow https://github.com/wesnoth/wesnoth/commit/3f646cc96547e57a258cc7e854abdd6da8ba734e
20171129 22:36:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20171129 23:08:55< irker525> wesnoth: Charles Dang wesnoth:master 2c12d1328ba6 / src/game_events/ (handlers.cpp manager_impl.cpp): Game Events: fixed a few oversights in 056d7ac8f88c https://github.com/wesnoth/wesnoth/commit/2c12d1328ba6fc6c45f5b7ed0eafac656ef53d65
20171129 23:08:58< irker525> wesnoth: Charles Dang wesnoth:master fb5fd3f3c478 / src/game_events/manager_impl.cpp: Game Events: made use of some emplace_back when constructing handlers https://github.com/wesnoth/wesnoth/commit/fb5fd3f3c4788c11826dd92a36b601e9e4929014
20171129 23:17:20-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection]
20171129 23:20:39-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20171129 23:21:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171129 23:39:17-!- sigurdfd [sigurdfd@dynamic-acs-72-23-110-196.zoominternet.net] has quit []
20171129 23:53:48-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20171129 23:54:01-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20171129 23:57:32-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
--- Log closed Thu Nov 30 00:00:38 2017