--- Log opened Fri Oct 21 00:00:46 2016 20161021 00:01:10< vultraz> it's tied to the ubuntu distro travis is set up to use or something 20161021 00:01:35< vultraz> celticminstrel: where is that chart of yours? 20161021 00:04:59< vultraz> pokepokepoke 20161021 00:11:20< vultraz> DeFender1031: for the record, I think we should be on gcc 5 since we're using c++11 20161021 00:11:27< vultraz> but, meh :| 20161021 00:12:05< DeFender1031> vultraz, yeah, that'd be nice. 20161021 00:12:18< Aginor> vultraz: that'd mean dropping debian stable as a supported platform 20161021 00:12:24< vultraz> i can't find celticminstrel's chart in my history 20161021 00:12:25< Aginor> I think that's unacceptable 20161021 00:12:28< vultraz> ah, that's it. 20161021 00:12:35< vultraz> when do they get a new stable? 20161021 00:12:43< Aginor> go google it yourself :) 20161021 00:13:40< DeFender1031> Aginor, does debian not have a package for 5? 20161021 00:14:07< vultraz> how does a release made in september not support gcc 5 :| 20161021 00:16:06< vultraz> well, 8.6 was released last month 20161021 00:16:25< vultraz> 8 itself was initially april 2015 20161021 00:18:11< vultraz> a search of the debian repo tells me jessie has 4.9. 20161021 00:18:18< vultraz> debian unstable has gcc 5 20161021 00:18:46< vultraz> ok, so we can go as high as gcc 4.9 I guess 20161021 00:20:11-!- travis-ci [~travis-ci@ec2-54-91-111-134.compute-1.amazonaws.com] has joined #wesnoth-dev 20161021 00:20:11< travis-ci> wesnoth/wesnoth#11681 (boost_to_std_regex - 2ad9a24 : Charles Dang): The build failed. 20161021 00:20:12< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/169395280 20161021 00:20:12-!- travis-ci [~travis-ci@ec2-54-91-111-134.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161021 00:20:17< vultraz> I think travis is still using trusty? 20161021 00:20:49< vultraz> we should point it at xenial 20161021 00:21:21-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20161021 00:27:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161021 00:32:14< Aginor> ubuntu 14.04, which is still widely used, only has 4.8 20161021 00:32:21< Aginor> http://packages.ubuntu.com/trusty/devel/gcc 20161021 00:32:39< Aginor> I feel like I'm repeating this every couple of months 20161021 00:32:59< vultraz> that's old LTS. 20161021 00:33:06< vultraz> 16.04 is new LTS 20161021 00:33:13< Aginor> it's still supported 20161021 00:33:45< vultraz> yes, but if we ever want to make travis compile with sdl 2.0.4 we'll likely not be supporting 14.04 20161021 00:34:06< Aginor> how come? 20161021 00:35:23-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161021 00:35:51< vultraz> trusty has 2.0.2 20161021 00:35:56< Aginor> anyway, what's the platforms we want to support? how large percentage of our users do we abandon by dropping support for certain platforms? 20161021 00:36:16< vultraz> currently travis doesn't *need* to build with 2.0.4, yes 20161021 00:36:18< Aginor> because gcc versions are also tightly linked to glibc versions 20161021 00:36:25< vultraz> it builds fine with 2.0.2 20161021 00:36:34< vultraz> but users need 2.0.4 20161021 00:36:54< vultraz> therefor I have already invalidated trusty support 20161021 00:36:55< Aginor> I will disappear very soon 20161021 00:37:00< Aginor> you have? 20161021 00:37:03< tad_carlucci> Depends on the build. If you link SDL 2.0.4 static as we do on Linux then the users are not effected, only those who build need 2.0.4 20161021 00:37:05< Aginor> where was the announcement? 20161021 00:37:41< vultraz> the gui2 canvas changes to a sw renderer. it inadvertently bumped the requirement to 2.0.4 on linux (from 2.0.2) 20161021 00:38:00< Aginor> ok 20161021 00:38:03< vultraz> anyone below that version gets rendering issues. 20161021 00:38:06< Aginor> that's the technical requirements 20161021 00:38:21< Aginor> what is the impact on potential usage share? 20161021 00:38:24< vultraz> anyone using anything below that versio* 20161021 00:38:27< vultraz> version** 20161021 00:38:49< vultraz> I don't know. 20161021 00:38:50< Aginor> figure out who it affects and if we care, that's the bit of maintaining the product from a lifecycle point of view 20161021 00:38:56 * Aginor feels like a broken record 20161021 00:39:12< vultraz> As I said, the change as inadvertent. 20161021 00:39:14< vultraz> was* 20161021 00:39:22< Aginor> so revert it then 20161021 00:39:23< Aginor> fix it 20161021 00:39:40< Aginor> or do the research and figure out if it's acceptable 20161021 00:39:46< vultraz> There is something to be said for a unified requirement on all platforms. 20161021 00:39:55< vultraz> 2.0.4 was already the minimum for Windows and Mac OS 20161021 00:39:57< Aginor> and if it is, announce to the world that it's no longer a supported platform 20161021 00:40:10< vultraz> yes, I can do that with the release. 20161021 00:40:13< Aginor> as of version X 20161021 00:40:18< vultraz> You underestimate me! :| 20161021 00:40:31< vultraz> Obviously this was going to be announced. 20161021 00:40:47< Aginor> but that will be an "we did it" 20161021 00:41:18< Aginor> instead of "we are soliciting feedback on our planned change, does anyone care about us dropping that as a platform?" 20161021 00:41:54< Aginor> I took away your chocolate vs I'm thinking about taking away your chocolate, do you care? 20161021 00:42:10< vultraz> I'm simply pointing out for the purpose of this discussion that support for old LTS is already in question, therefor the existence of gcc 4.8 on it is not the final say in what to point travis to. 20161021 00:42:39< Aginor> travis is irrelevant to this discussion, I'm talking about the platforms we support 20161021 00:43:01< Aginor> our CI tools should test the platforms we care about 20161021 00:43:06< Aginor> (within reason) 20161021 00:44:36< vultraz> That's the point 20161021 00:45:16< vultraz> I suspect the number of people who still use trusty AND cannot upgrade to xenial AND *build* wesnoth is marginal. 20161021 00:46:30< Aginor> well, if we suspect it, it's fine 20161021 00:47:09< vultraz> however, I am not the ubuntu packager. If anyone has statistics they do. 20161021 00:47:11< Aginor> I'm sure ubuntu has usage statistics hidden away soemwhere, why not try to find them and figure out of that suspicion is corect? 20161021 00:48:00< vultraz> that would be Rhonda IIRC. 20161021 00:48:26< vultraz> or someone else 20161021 00:48:32< vultraz> I think the latter, actually. 20161021 00:48:40< vultraz> In which case I don't know exactly who. 20161021 00:49:07< shadowm> Rhonda and vincent_c both work on the Debian and Ubuntu packages. 20161021 00:49:17< vultraz> vincent_c, ok. 20161021 00:49:27< shadowm> I said both. 20161021 00:49:38< vultraz> Yes 20161021 00:49:44< vultraz> I'm noting the second name. 20161021 00:50:45< vultraz> it is then they who would most likely have the stats we need. 20161021 00:51:10< tad_carlucci> vultraz, Actually, I looked at the builds going out and it's a shared lib, so I'm wrong on the static build. But, I agree, the number who can't or won't upgrade is probably tiny. 20161021 00:51:36-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 00:52:44< vultraz> IF we can agree dropping trusty support is fine, I see no reason we cannot bump min compiler support to gcc 4.9 since debian jessie supports it. 20161021 00:53:16< vultraz> and IIRC, iceiceice said 4.9 is at least c++11 feature-complete, despite it not being official until gcc 5. 20161021 00:53:19-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Read error: Connection reset by peer] 20161021 00:53:26< shadowm> (And please please don't ask me about this crap. There's an equal number of valid and invalid arguments from both sides to consider and I'm not in the mood for sisyphean debates.) 20161021 00:53:49< vultraz> I have no interest in such a debate. 20161021 00:54:22< shadowm> (I know you don't have an interest in anything that doesn't support your own highly-biased opinions.) 20161021 00:54:48< vultraz> Untrue. 20161021 00:54:57< tad_carlucci> Aginor, If you ship wesnoth on Linux, the requirement on the users machine is any SDL2 2.0 version. I just checked. The executable does not care about 2.0.2 or 2.0.4 so it's jsut they'll have some issues on the screen 20161021 00:57:42-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev 20161021 01:32:41-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009] 20161021 01:32:57-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20161021 01:34:32-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 250 seconds] 20161021 01:44:37-!- gfgtdf_ [~chatzilla@x4e368475.dyn.telefonica.de] has joined #wesnoth-dev 20161021 01:46:57-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev 20161021 01:47:36-!- gfgtdf [~chatzilla@x4e363b46.dyn.telefonica.de] has quit [Ping timeout: 252 seconds] 20161021 01:47:47-!- gfgtdf_ is now known as gfgtdf 20161021 01:49:51< vultraz> shadowm: am I correct in remembering that you told me to not remove any of the info columns in the addons manager? 20161021 01:55:30-!- iceiceice [~chris@50-245-222-235-static.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] 20161021 02:02:21-!- gfgtdf [~chatzilla@x4e368475.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]] 20161021 02:03:07 * vultraz ponders placement of download buttons in the new addons manager 20161021 02:03:21< vultraz> I believe i got feedback saying the download buttons in rows were redundant 20161021 02:12:29< Aginor> tad_carlucci: yes, because they're all ABI compatible and it's mainly bugfix releases 20161021 02:12:50< Aginor> so it means we're going to get a lot of bug reports :) 20161021 02:13:38< vultraz> We've already had bug reports of from pre 2.0.4 users 20161021 02:14:00< mattsc> celticminstrel: thanks for the comment on the inconsistent spacing, but guess who introduced that into the file ;) 20161021 02:16:06< irker958> wesnoth: mattsc wesnoth:master 6ff7e1112d83 / data/ai/micro_ais/cas/ca_fast_combat_leader.lua: Fast Micro AI: clear all persistent variables after use https://github.com/wesnoth/wesnoth/commit/6ff7e1112d836046c66bbb189844a95b3a0c2625 20161021 02:16:08< irker958> wesnoth: mattsc wesnoth:master 7647a4ad4213 / data/ai/micro_ais/cas/ca_fast_combat.lua: Fast Micro AI: replace tabs by spaces https://github.com/wesnoth/wesnoth/commit/7647a4ad4213d955db5dd85e82afffe19dab0a59 20161021 02:16:57< tad_carlucci> Aginor, So we should back of any work which requires 2.0.1 or later? 20161021 02:17:25< vultraz> No. 20161021 02:19:09< vultraz> In fact, we need 2.0.4 on windows and mac os explicitly because a bugfix in that release. 20161021 02:19:16< tad_carlucci> vultraz, I know that. The issue is that there might be some people who didn't or can't upgrade from trusty and can't find the ppa to upgrade to 2.0.4 or install it if they do. 20161021 02:19:48< vultraz> Firstly, you just said earlier that number is likely small. 20161021 02:20:12< vultraz> Secondly, why cannot we find the ppa and advertise it? 20161021 02:21:32< Aginor> tad_carlucci: that depends entirely on the decision is with regards to supported platforms :) 20161021 02:21:41< tad_carlucci> vultraz, I tried but it's been a long time and I forget the right place to look. Canonical has it out but you need to add the ppa. Or grab it from Debian and install it with dpkg. Travis would not need the version hack if we could do it. 20161021 02:21:47< Aginor> tad_carlucci: at the end of the day, it's a product cycle decision 20161021 02:25:04< vultraz> http://www.ubuntuupdates.org/ppas this useful at all? 20161021 02:25:40< tad_carlucci> vultraz, It's been a couple years and I don't remember. Dont' think I found that site googling for the upgrades, 20161021 02:30:28< vultraz> blagh 20161021 02:30:30< vultraz> http://www.ubuntuupdates.org/package_metas?exact_match=1&q=libsdl2 20161021 02:30:35< tad_carlucci> Ended up on the same page. Download from debian but no ppa to get it 20161021 02:34:19-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has joined #wesnoth-dev 20161021 02:56:34< tad_carlucci> Oh hell 20161021 02:57:09< tad_carlucci> OK. PR time. This will actually fix all sorts of crashes. 20161021 03:01:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 03:02:03< tad_carlucci> mattsc, PR 836 fixes your crash. I'm 100% sure but test it and have it merged. 20161021 03:04:12< celticminstrel> vultraz, DeFender1031: https://wiki.wesnoth.org/User:Celtic_Minstrel/WesnothCxx11Support 20161021 03:04:13< celticminstrel> vultraz: The chart suggests that Mint, OpenSUSE, and Slackware may need a new stable before we can make 4.9 the minimum, though the latter two do have a release with 5+ and I'm not sure whether it is considered the current stable version. (Admittedly the chart is a little old by now and some of them might have a new stable release by now, but that's why I said "according to the chart".) 20161021 03:04:15< celticminstrel> Aginor: I'm actually not terribly concerned about supporting Ubuntu 14.04 trusty, due to this: http://packages.ubuntu.com/trusty/devel/wesnoth 20161021 03:04:15< celticminstrel> mattsc: Uh, it's entirely possible that I introduced inconsistent indentation... 20161021 03:05:07< vincent_c> vultraz / Aginor / shadowm: just skimmed through my IRC backlog and noticed that someone was asking about PPA usage stats, so here you go: https://www.vcheng.org/wesnoth-ppa-stats.txt 20161021 03:05:23< vincent_c> ^ Rhonda too I guess 20161021 03:05:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20161021 03:06:52< celticminstrel> vincent_c: So does that render my argument just now invalid? 20161021 03:06:55< shadowm> vincent_c: That's the PPA only, though, not the packages in Ubuntu's official repositories + backports? 20161021 03:07:09< vincent_c> correct, PPA only 20161021 03:07:23 * celticminstrel doesn't even know what PPA means. 20161021 03:07:32< celticminstrel> Presumably one of the P's is "package"... 20161021 03:07:32< shadowm> Personal package archive. 20161021 03:07:36< celticminstrel> Ah. 20161021 03:07:47< shadowm> Think unofficial/3rd-party software repository. 20161021 03:08:08< celticminstrel> shadowm: Note that, according to the link I just posted, the official trusty repositories only have Wesnoth 1.10. 20161021 03:08:55< shadowm> Yeah, a lot of people wanted help with building Wesnoth 1.12 on trusty at the time, though, and it was indeed possible and I posted a set of instructrions myself. 20161021 03:09:20< shadowm> I think it was trusty anyway? Not sure 20161021 03:09:55< celticminstrel> Okay. 20161021 03:09:57< shadowm> Whichever was the last LTS that didn't have the version of Boost.Filesystem that we required. 20161021 03:10:14< celticminstrel> Well I'm pretty sure it's still possible as long as we stick to 4.8, and I think there's at least one other reason to do so as well. 20161021 03:10:46< celticminstrel> I really don't think it's that big a deal that we have to use Boost regex instead of std::regex. It's not worth bumping the minimum just for that. 20161021 03:10:55< shadowm> Oh, never mind, it was precise. 20161021 03:11:21< celticminstrel> Still, I'm not too worried about supporting a distribution that doesn't even have 1.12 in its official repos. 20161021 03:11:34< tad_carlucci> PPA --> Personal Package Archive (n) The name Cannonical uses instead of RPM or other modern Linux software packages with dependency management. 20161021 03:11:34< shadowm> trusty-backports does have 1.12.5 though (not 1.12.6 for some reason...?). 20161021 03:12:05< shadowm> tad_carlucci: "PPA" isn't analogue to RPM, dpkg is analogue to RPM. 20161021 03:12:11< celticminstrel> Ah, okay. In that case, I guess there's good reason to keep supporting trusty. 20161021 03:12:31< tad_carlucci> Bah. I just say 'yaourt -Syua' and don't worry about it. 20161021 03:12:38< celticminstrel> ...yaourt? 20161021 03:12:42< celticminstrel> Sounds tasty. 20161021 03:13:24< shadowm> Also Canonical didn't invent the package management framework Ubuntu uses, which is dpkg, which was made by Debian for Debian. 20161021 03:13:37< tad_carlucci> It's an alternative to the standard Arch package installer, supports automatic building for packages which don't have 'official' arch support. 20161021 03:15:18-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai] 20161021 03:18:02-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 03:20:22-!- 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.] 20161021 03:21:11-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161021 03:30:48-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai] 20161021 03:42:04< vultraz> celticminstrel: I am not advocating a bump to 4.9 for the purpose of using std::regex alone. I'm putting it forth as a possibility if we decide to officially no longer support trusty, since we won't need to worry about gcc versions on ubuluty with xenial and debian jessie has 4.9 20161021 03:42:45< celticminstrel> vultraz: Part of my point was that trusty is (probably) not the only reason for staying on 4.8... 20161021 03:44:08< vultraz> Mint 18 (Sarah) is out since you updated your chart. 20161021 03:44:55< celticminstrel> The wiki claims that the mapgen kernel has access to a global Rng object... is that really the case... 20161021 03:45:17< celticminstrel> vultraz: Okay, and what about OpenSUSE and Slackware? I don't really get how their setups work, so the chart may say they're fine, but I'm uncertain. 20161021 03:47:09< vultraz> Slakware 14.2 has gcc 5.3 as default if I'm reading their announcement correctly 20161021 03:47:14< vultraz> So that matches up with Xenial 20161021 03:47:51< celticminstrel> And do they have something similar to the Debian oldstable or Ubuntu LTS? 20161021 03:48:05< vultraz> No idea 20161021 03:48:13< vultraz> their site looks like it's from 1990 20161021 03:48:33< vultraz> OpenSUSE has a surprisingly modern site. 20161021 03:49:48< vultraz> OpenSUSE 42.2 will be out in "29 days" 20161021 03:50:28-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds] 20161021 03:50:48< celticminstrel> And the current version has GCC 5? 20161021 03:52:11< vultraz> well your chart says "tumbleweed" does. 20161021 03:52:37< vultraz> and that 42.1 has 4.8 20161021 03:53:26< vultraz> Essentially I consider the important distros Debian and Ubuntu. 20161021 03:54:17< vultraz> So the only thing we need to consider if bumping to 4.9 is whether we'll no longer be supporting trusty. 20161021 03:54:27< celticminstrel> Well then, considering that, Ubuntu and Debian should be the ones where we care most about possibly supporting long-term support releases. 20161021 03:54:32< pydsigner> Debian and Ubuntu? That's basically only one 20161021 03:54:44< celticminstrel> But I think we already dropped Debian oldstable? 20161021 03:54:51< pydsigner> And Arch is pretty big 20161021 03:54:57< vultraz> IIRC 20161021 03:55:10< vultraz> i think no one cared about dropping obstable. 20161021 03:55:13< pydsigner> Although the rolling release thing doesn't make it tough to support I guess 20161021 03:55:36< vultraz> For Ubuntu, supporting current LTS min is a good target. 20161021 03:55:56< celticminstrel> Any idea when the LTS will be shifted forward? 20161021 03:56:14< vultraz> 16.04 is the new LTS :/ 20161021 03:56:19< vultraz> (xenial) 20161021 03:56:29< vultraz> it seems to bump every 2 years. 20161021 03:56:53< vultraz> Next LTS should be April 2018 20161021 03:57:45< pydsigner> Yeah that's the cycle 20161021 03:57:52< pydsigner> Spring even years 20161021 03:58:36< vultraz> One might say we should support any LTS as long as it's supported 20161021 03:58:43< vultraz> but I think that's stretching it 20161021 03:59:08< pydsigner> I don't think 1.13 needs to support 14.04 by any means 20161021 04:00:06< vultraz> xenial even has gcc 5 so we can bump to 5 proper once debian unstable becomes stable. 20161021 04:00:06< celticminstrel> I wonder if we should port the default map generator to Lua, too. 20161021 04:00:11< celticminstrel> Low priority, but something to consider. 20161021 04:00:16< vultraz> though I have no idea when that will happen 20161021 04:00:43< celticminstrel> I also think that supporting "map_generation=lua" is kinda poor form. I'd prefer to use "map_generation=cave" and have it invoke the Lua for me. 20161021 04:01:01< vultraz> google seems to fail me there 20161021 04:01:10< vultraz> anyone know how long the debian stable cycle is? 20161021 04:01:25< celticminstrel> I guess "map_generation=lua" does make a lot of sense for a generator that's very specifically customized for a particular scenario though... 20161021 04:02:34< vultraz> gcc 4.9 should at least ensure we don't run into any more stuff like this regex business 20161021 04:03:15< celticminstrel> But this regex business isn't particularly important. 20161021 04:03:26< vultraz> No 20161021 04:03:30< vultraz> It is not. 20161021 04:03:42< celticminstrel> Good, I'm glad we agree on that. 20161021 04:03:58< vultraz> But the general point being that it's better to use the closest compiler to gcc5 as possible. 20161021 04:04:33< vultraz> So we don't run into something actually important that gcc screwed up/didn't implement. 20161021 04:04:57-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 04:05:00< Aginor> I disagree 20161021 04:05:27< vultraz> We're already limited by MVC 12, let's not be limited by gcc too. 20161021 04:05:52< celticminstrel> Since we're already limited by MSVC 12, it seems pointless to try not to be limited by GCC too. 20161021 04:06:16< vultraz> fewer limitations = better 20161021 04:06:18< celticminstrel> I don't think there are any important language features that 4.8 doesn't support anyway, are there? 20161021 04:06:29< Aginor> or let's just support gcc 6.1 and latest MVC then 20161021 04:06:29< tad_carlucci> Why are we limited by MSVC? 20161021 04:06:41< vultraz> because we still support MSVC 2013 20161021 04:06:52< vultraz> which doesn't have fully-implemented modern c++ 20161021 04:07:10< celticminstrel> If you drop support for MSVC 2013 and require GCC5, I likely won't be able build anymore at all. 20161021 04:07:15< celticminstrel> On either platform. 20161021 04:07:30< vultraz> We can't require gcc 5 yet 20161021 04:07:40< celticminstrel> (Though I suppose I could install MSVC 2015 if I really have to. I've heard it's worse than 2013, but I dunno.) 20161021 04:07:49< tad_carlucci> celticminstrel, Why can't you upgrade to MSVC14? 20161021 04:08:26< celticminstrel> Is the free version of MSVC 14 fully-featured or does it omit some things? I have MSVC 2013 Ultimate here. 20161021 04:08:52< vultraz> no idea 20161021 04:08:53< celticminstrel> tad_carlucci: It's not that I can't. 20161021 04:12:05< vultraz> Some of us still build on msvc 2013, so it's a valid limitation. afaik none of us build using gcc 4.x, except travis as a 'minimum support guard' kind of thing. Makes sense to reduce limitations there. 20161021 04:12:31< iceiceice> celticminstrel, in my experience gcc has some annoying bugs regarding constexpr 20161021 04:12:52< iceiceice> also there is an annoying thing about brace initialization in gcc 4 20161021 04:13:01< celticminstrel> What about brace initialization? 20161021 04:13:03< iceiceice> u cannot do aggregate initializatoin via a brace init list 20161021 04:13:03< vultraz> I'm not sure if MSVC 2013 is what's preventing us from using c++14 either. 20161021 04:13:11< iceiceice> i encounteered this when testing primer 20161021 04:13:21< celticminstrel> There's an annoying thing about brace initialization in my clang ~3.2, too... sounds similar to what you say... 20161021 04:13:43< celticminstrel> vultraz: Yes, MSVC 2013 is preventing us from using C++14. 20161021 04:13:46< iceiceice> sry i'm not explaining it well 20161021 04:13:52< iceiceice> i made a SO question about it once 20161021 04:14:00< Aginor> when is clang going to become an issue? 20161021 04:14:22< iceiceice> http://stackoverflow.com/questions/39005700/list-initialization-of-aggregates-when-can-it-invoke-copy-constructor 20161021 04:14:28< celticminstrel> vultraz: If you have a specific C++14 language feature you want, we might be able to wire it into global.hpp, though. 20161021 04:14:34< celticminstrel> Aginor: What? 20161021 04:14:42< vultraz> celticminstrel: mostly i just want auto arguments :P 20161021 04:14:59< celticminstrel> vultraz: Ah, that's not gonna work, sorry. 20161021 04:15:16< Aginor> if we decide to upgrade to newer, better compilers because we decide that they allow shinier features, when is clang going to become the bottleneck? 20161021 04:15:22< vultraz> also c++14 has template variables 20161021 04:15:37< vultraz> and lambda local variable declarations. 20161021 04:15:43< celticminstrel> You can get the effect of template variables in C++11. 20161021 04:15:50< celticminstrel> Just make a template class with a single static member. 20161021 04:16:09< Aginor> I thought we were supporting c++11, not c++14 20161021 04:16:15< vultraz> Yes. 20161021 04:16:23< vultraz> As long as we support MSVC 2013 20161021 04:16:23< celticminstrel> By lambda local variable declarations, do you mean the thing where the lambda capture list assigns an expression to a variable? 20161021 04:16:36< vultraz> celticminstrel: probably, yes 20161021 04:16:54< Aginor> ok, I'll try again 20161021 04:16:57< celticminstrel> Well, that's really just a minor convenience. You can easily just declare the variable inside the function instead. 20161021 04:17:24< vultraz> celticminstrel: true 20161021 04:17:30< Aginor> what's the main driving reason for us to cut off support for older, not EOLed platforms? 20161021 04:17:37< vultraz> celticminstrel: there's no pressing need for c++14 right now 20161021 04:17:39< celticminstrel> I don't even know. 20161021 04:17:59< vultraz> Aginor: getting gcc 5 as the minimum. 20161021 04:18:32< Aginor> why? 20161021 04:18:37< celticminstrel> I don't even know. 20161021 04:18:50< vultraz> because iceiceice tells us that that is the version that fully implements c++11 20161021 04:19:15< celticminstrel> But MSVC 2013 doesn't fully implement C++11 either. 20161021 04:19:29< vultraz> Yes, and I don't particularly like that. 20161021 04:19:34< iceiceice> we probably shouldn't support that either tbh 20161021 04:20:11< vultraz> We kept it as legacy support for zookeeper and celmin. 20161021 04:20:20< celticminstrel> I'm not sure I like that they chose ' as the digit separator in C++14... 20161021 04:21:00< vultraz> Aginor: now that we use c++11 we should try to migrate our minimum supported compiler versions to those which fully support modern c++ 20161021 04:21:05< Aginor> someone who actually does development on windows: does VC15 require windows 7 or 10? 20161021 04:21:18< Aginor> vultraz: again, why? 20161021 04:21:22< iceiceice> tbh even msvc 2015 C++11 support is deplorable, there are a numbe rof language features they just aren't doing 20161021 04:21:44< iceiceice> and they just get away with it b/c they are microsoft 20161021 04:21:56< Aginor> because it's tidier? or because it causes it minor inconveniencves? or because it introduces horrible bugs in the compiled binaries? 20161021 04:21:57< vultraz> for the record, dropping Msvc 2013 means dropping windows xp support oo 20161021 04:21:59< tad_carlucci> Visual Studio 2015 requires Windows 7, or later. 20161021 04:22:06< vultraz> too* 20161021 04:22:17< Aginor> is Vista still a supported platform? 20161021 04:22:29< Aginor> or do we toss that out too? 20161021 04:22:32< vultraz> Aginor: so we can use all features and don't run into bugs where the compilers didn't fully implement the standard 20161021 04:22:41< vultraz> Aginor: vista would be tossed too, yes, despite not being EOL 20161021 04:22:53< vultraz> but let's be honest 20161021 04:22:55< vultraz> who's using vista :P 20161021 04:23:45< Aginor> vultraz: I am not finding any concrete reasons in your arguments for these changes, apart from "new and shiny", which isn't doing much to convince me 20161021 04:23:48< tad_carlucci> Vista goes EOL on April 11, 2017. I'd have moved it forward 10 days, myself. 20161021 04:24:05< vultraz> heh 20161021 04:24:07< vultraz> xD 20161021 04:24:09< celticminstrel> Theoretically, Wesnoth still supports XP (for users, not for devs). 20161021 04:24:13< Aginor> tad_carlucci: no, then people might not think it actually happens 20161021 04:24:26< Aginor> tad_carlucci: and that'd be terrible :D 20161021 04:24:48< vultraz> Aginor: it's an inconvenience, mostly. 20161021 04:25:07< celticminstrel> But I'm with Aginor basically, I don't see any reason to bump requirements. 20161021 04:26:17< vultraz> *IF* we decide to no longer officially support Ubuntu Trusty since they don't ship SDL 2.0.4 as their default and as such any new people compiling on that platform will have rendering problems, then there is no reason not to bump the min compiler version to GCC 4.9. 20161021 04:26:29< vultraz> That's essentially the thing. 20161021 04:26:41< vultraz> MSVC 2013 is a totally separate issue. 20161021 04:26:52< Aginor> to put it in business speak: there doesn't appear to be a business reason for that change, there's only potential negative user impact with little to no technical reason 20161021 04:27:06< Aginor> vultraz: C compiler is a different kettle of fish to a shared library 20161021 04:27:38< Aginor> c compilers are linked to c-libraries, which underpins the entire operating system, a shared library is a lot less onerous to deal with for a user 20161021 04:27:44< celticminstrel> Ooooh, std::quoted sounds really handy. 20161021 04:27:54< celticminstrel> I had to basically implement it myself in BoE. 20161021 04:27:59< celticminstrel> Or something similar anyway. 20161021 04:29:03< vultraz> Aginor: there's another reason I haven't look into: how compatible are our minimum version requirements with those of Steam? 20161021 04:29:16< Aginor> wget && tar zxvf SDL2.0.5.tar.gz && cd SDL2.0.5 && ./configure && make && sudo make install && cd ~/wesnoth/myfavouritefolder && cmake SDL2DIR=/usr/local && make -j8 20161021 04:29:25< vultraz> granted, that's not *really* a serious issue, but still. 20161021 04:30:02< vultraz> Aginor: yeah, see, if you start saying that, I reply "why can't a debian stable user update their compiler to gcc 5" when you say we can't bump to 5. 20161021 04:30:20< iceiceice> Aginor, it really sucks not to be able to use constexpr 20161021 04:30:21< Aginor> vultraz: because of glibc 20161021 04:30:30< iceiceice> it forces you to write code that is more complicated and longer 20161021 04:30:32< tad_carlucci> Aginor, that 'sudo' is the only showstopper. IF you're on Trusty and can do that dpkg will save an hour or two compile time., 20161021 04:30:44< iceiceice> it means that we have tons of strings an dnumbers and colors that are constants 20161021 04:30:47< iceiceice> and so on 20161021 04:30:54< iceiceice> and they cannot be declared and efeind in a header 20161021 04:30:59< iceiceice> they have to be declared extern 20161021 04:31:02< iceiceice> and placed in a translation unit 20161021 04:31:08< iceiceice> and then, we have to decide, is it in wesnoth lib? 20161021 04:31:12< iceiceice> is it in wesnoth-extra? 20161021 04:31:14< iceiceice> is it in wesnoth-core? 20161021 04:31:18< iceiceice> and if not we get stupid linker issues 20161021 04:31:43< iceiceice> theres no reason to have problems like that, if we required constexpr support we could just declare them to be constexpr variables in the header and be done with it 20161021 04:31:51< iceiceice> as long as they are not ODR-used then that is all u need 20161021 04:32:02< vultraz> ^ see, there's a good reason for updating 20161021 04:33:00< tad_carlucci> Two separate issues. The platform issue for SDL2 2.0.4 effects users. The toolset issue for C++14 only effects developers and builders. 20161021 04:33:00< iceiceice> (i think ODR-used is not the right property that i shoul dbe referring to but hopefully it explains some advantage) 20161021 04:33:18< vultraz> what tad_carlucci says is true 20161021 04:33:41< tad_carlucci> I'm sort of with Aginor about the platform issue. But I'm with iceiceice on the toolset issue. 20161021 04:33:43< vultraz> but IF we bump something so it doesn't negatively affect the users WHY should we also not do something to benefit the developers! 20161021 04:34:48< celticminstrel> iceiceice: If they're declared const I'm pretty sure they can go in a header. 20161021 04:35:01< vultraz> Because if we retain 4.8 as the minimum, we're essentially saying "sure, you can build on trusty, but you game won't run right unless you update sdl" 20161021 04:35:04< celticminstrel> Global const declarations are implicitly static IIRC. 20161021 04:35:29< tad_carlucci> IFF there is a way to back off 2.0.4 and only require 2.0.0 I'd say do that. But I see no reason a developer/builder cannot upgrade to the latest-and-greatest toolset since they're almost all free. 20161021 04:35:32< vultraz> Aginor has a point that that's probably easier, but I thought the goal was for out-of-the-box support 20161021 04:35:35< celticminstrel> Even if they aren't you could explicitly declare them static. 20161021 04:36:06< vultraz> tad_carlucci: we *cannot* backpedal to 2.0.0 and we should not have different requirements on Linux over Windows and Mac OS! 20161021 04:36:11< iceiceice> if they aren't constexpr and they have nontrivial initialization, then u can get a static initialization fiasco that way 20161021 04:36:18< iceiceice> iirc 20161021 04:36:33< celticminstrel> Oh, if they have nontrivial initializations, then there could be a problem. yes. 20161021 04:36:33< iceiceice> constexpr ensures that there's not going to be any runtime initialization of those things 20161021 04:37:11< celticminstrel> We do have the CONSTEXPR macro though. 20161021 04:38:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 04:38:49< vultraz> tad_carlucci: sure, i could revert all the changes to the GUI2 canvas involving sdl_renderer contexts, but it seems stupid to have 2.0.4 as a minimum on two platforms if the minimum is lower on another and any you then need to avoid using code that wasn't fixed post-2.0.2! 20161021 04:39:16< vultraz> s/and any you/if you 20161021 04:39:28< iceiceice> celticminstrel, i dont think the macro is at all a subsitutte 20161021 04:40:01< iceiceice> celticminstrel, i think the easiest substitute would be something like 20161021 04:40:03< vultraz> tad_carlucci: since then it imposes 2.0.2 as a *maximum*! 20161021 04:40:11< iceiceice> instead of global constants you could make inline functions in a header for each such variable 20161021 04:40:14< vultraz> which is dumb 20161021 04:40:21< iceiceice> and they could be constexpr conditional on c++11 20161021 04:40:34< iceiceice> but its still uglier than just constexpr vairables 20161021 04:40:50< tad_carlucci> vultraz, That's correct. Would have avoided this entire issue if the developers used the user-minimums as their toolset-maximums. 20161021 04:40:58< iceiceice> idk i think that 20161021 04:41:02< Aginor> 17:40 < vultraz> tad_carlucci: since then it imposes 2.0.2 as a *maximum*! 20161021 04:41:08< Aginor> that's really backwards logic 20161021 04:41:09< iceiceice> there needs to be a way to resolve stuff like this other than just voting it on every 6 months or something 20161021 04:41:15< Aginor> but tad_carlucci actually has a good point 20161021 04:41:16< iceiceice> like, people should agree that we track debian stable 20161021 04:41:22< iceiceice> or ubntu stable 20161021 04:41:28< iceiceice> or some common denominator 20161021 04:41:39< Aginor> let's make a docker image for building wesnoth inside that has the minimum linux tools 20161021 04:41:41< iceiceice> and we only deviate from that if theres a big problem 20161021 04:41:53< iceiceice> rather than like, every time want to increase the dependencies, there needs to be hours of arguing 20161021 04:42:05< Aginor> that also lowers the burden for new devs to get the environment up and running 20161021 04:43:15< tad_carlucci> Aginor, Can we do that using a free CI like-Travis-but-not-Travis? 20161021 04:43:15< iceiceice> Aginor, how many people actually know how to use docker though? 20161021 04:43:15< Aginor> tad_carlucci: no idea, I think the main problem would be in hosting 20161021 04:43:37< celticminstrel> But we already have Travis... 20161021 04:43:44< iceiceice> Aginor, another approach is the thing they use for "linux steam runtime" 20161021 04:43:53< tad_carlucci> Or want to use docker. Left alone I'd just grab some backports and build a new VM for a build platform and remote compile on it. 20161021 04:43:54< iceiceice> where its like, it sets up a chroot manually 20161021 04:43:57< iceiceice> and installs deps there 20161021 04:44:01< iceiceice> i guess that is quite similar to docker 20161021 04:44:14< iceiceice> idk i kind of think the way we do it now where like 20161021 04:44:15< Aginor> iceiceice: you waste less space that way 20161021 04:44:21< iceiceice> theres some bash commands you cut and paste to install the deps 20161021 04:44:24< iceiceice> is pretty good 20161021 04:44:25< celticminstrel> Okay... the way to get a child tag is helper.child(cfg, tag_name), right... 20161021 04:44:53< vultraz> iirc 20161021 04:45:00< iceiceice> Aginor i think the main barrier to get started developing is that, building from source from scratch takes about 40 min 20161021 04:45:35< iceiceice> idk i would be surprised if its about installing the deps 20161021 04:45:43< vultraz> Aginor: there are essentially 2 options: bump the minimum or lower the maximum. I prefer the former 20161021 04:46:08< Aginor> vultraz: can you please explain how we are lowering the maximum 20161021 04:46:15< Aginor> I do not follow your logic 20161021 04:46:18< Aginor> does it break? 20161021 04:46:22< Aginor> does it not compile? 20161021 04:46:22< vultraz> Aginor: because we then cannot use anything that was bugged in 2.0.2 20161021 04:46:47< vultraz> Aginor: my changes cause spectacular rendering issues without 2.0.4 20161021 04:47:02< vultraz> backgrounds not appearing, lines not being drawn... 20161021 04:47:31< vultraz> Everyone who reported these issues also reported them fixed with 2.0.4 20161021 04:48:02< vultraz> By saying we need to maintain 2.0.2 as the max on linux, it means we cannot make use of any bugfixes in .0.3 or .0.4 20161021 04:48:16< tad_carlucci> But you'd have seen them far sooner if YOU'd been using 2.0.2, vultraz .. and then you'd probably have coded differently and avoided this mess 20161021 04:48:38< celticminstrel> I'd say it's not too late to revert the canvas commit, too. 20161021 04:48:40< vultraz> tad_carlucci: ah, but 2.0.4 is required on windows due to a different bugfix! :) 20161021 04:49:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161021 04:49:03 * tad_carlucci head >> wall 20161021 04:49:54< vultraz> at least, as far as I know 20161021 04:50:02< Aginor> yes, but we had something stable that supported our features, then we introduced further functionality for which wasn't tested everywhere and then we ended up in this mess 20161021 04:50:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 04:50:07< pydsigner> cat wall → tad_carlucci's head 20161021 04:50:31< tad_carlucci> Anyway. I say done is done. The subject should be how to avoid this issue in the future rather than wishing we didn't have it now. 20161021 04:50:36< Aginor> I think tad_carlucci appended his head to the wall 20161021 04:50:55< pydsigner> Yeah I didn't know what to put for the rest of the wall though 20161021 04:51:10< vultraz> The solution is to never again have platform-dependent minimums. 20161021 04:51:13< pydsigner> maybe 2x4\ntad_carlucci's head? 20161021 04:51:18< Aginor> I'm going to leave the computer instead of arguing more on the internets 20161021 04:51:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit] 20161021 04:51:29< Aginor> vultraz: that doesn't make sense when supporting multiple platforms 20161021 04:51:41< Aginor> you yourself is arguing for it 20161021 04:51:51 * Aginor leaves 20161021 04:52:09< vultraz> if 2.0.4 is min on windows and mac os, it should be min on linux too 20161021 04:52:14< iceiceice> i tend to agree that platform-dependent minimums are confusing 20161021 04:52:39< iceiceice> libs should have good cross-platform support, if 2.0.2 is bugged then we should avoid it 20161021 04:52:47< vultraz> ^^^^^ 20161021 04:52:55< iceiceice> idk its complicated 20161021 04:53:08< iceiceice> vultraz, one of the things about the arguments i make though for C++ compiler versions 20161021 04:53:16< vultraz> I do not appreciate being forced to support upstream bugs :| 20161021 04:53:17< tad_carlucci> iceiceice, The only issue I see is for locked-down systems (like Travis) where it's hard-to-impossible to upgrade the libs. 20161021 04:53:23< celticminstrel> Okay, so generating a percent chance should be... wesnoth.random(1,100) or wesnoth.random(0,99)...? 20161021 04:53:40< iceiceice> celticminstrel, the world may never know 20161021 04:53:46< pydsigner> wesnoth.random(0,100)? 20161021 04:53:56< celticminstrel> pydsigner: That's 101 possible results. 20161021 04:54:12< celticminstrel> Unless it assumes an open range... 20161021 04:54:14< vultraz> celticminstrel: pretty sure it's 1..100 20161021 04:54:16< iceiceice> off-by-one errors + random result not easily testable = T_T 20161021 04:54:20< vultraz> 1,100 means 1 OR 100 20161021 04:54:25< iceiceice> i would just look in C++ source every time 20161021 04:54:29< vultraz> or maybe that's just helper.rand 20161021 04:54:43< iceiceice> vultraz, the thing is that, if u want the game to compile with msvc, 20161021 04:54:45< pydsigner> The way you test random is by repeating tests millions of times :P 20161021 04:54:54< iceiceice> then u just cant get constexpr anytime soon 20161021 04:55:15< iceiceice> so as much as i prefer to like, make rigorous requirements of C++11 support, 20161021 04:55:16< vultraz> iceiceice: there is little reason to continue supporting msvc 2013 20161021 04:55:24< tad_carlucci> pydsigner, Or shim a replacement rand function which gives specific sequences to test the edges. 20161021 04:55:25< vultraz> *however* 20161021 04:55:26< iceiceice> the realities of the project are that ur going to have to support msvc 20161021 04:55:30< vultraz> that is a different problem 20161021 04:55:41< vultraz> right now I want to get this sdl bullshit dealt with 20161021 04:55:46< vultraz> then we can discuss msvc 20161021 04:56:30< celticminstrel> Should I avoid generating spurious random numbers? 20161021 04:56:39< celticminstrel> (ie, if chance is 100, skip the random number generation) 20161021 04:56:41< vultraz> iceiceice: if we drop msvc 2013 i think we can also jump to c++14 in the process. 20161021 04:56:52< vultraz> but again 20161021 04:56:54< vultraz> another issue 20161021 04:57:16< tad_carlucci> OK. How many hours work are we talking to fall back to 2.0.2 everywhere vs lost or annoyed users who can't upgrade or leave because it's too much hassle? 20161021 04:57:50< iceiceice> i wonder how hard it is to host a PPA on wesnoth.org or something? 20161021 04:57:50< vultraz> likely many hours 20161021 04:57:57< iceiceice> to get proper dependencies on traivs? 20161021 04:58:15< vultraz> tad_carlucci: one of the requirements for 2.0.4 on windows dates back to the sdl2 transition 20161021 04:58:26< tad_carlucci> iceiceice, probably better to get a cannonical account and host it there, and 'pretty easy' as I recall 20161021 04:58:28< iceiceice> tad_carlucci, u could probably like, compile SDL2 from source in the travis-ci home directory 20161021 04:58:28< vultraz> tad_carlucci: some pre-2.0.4 compatibility code was removed and we made 2.0.4 the min 20161021 04:58:53< iceiceice> i think SDL2 compiles quite quickly 20161021 04:59:21< vultraz> tad_carlucci: adding that back would require digging through logs, restoring code, fixing conflicts... testing...everyone with 2.0.4 rolling back to 2.0.2... 20161021 04:59:30< tad_carlucci> iceiceice, Basically pull the package from Debian, do some light work, and upload it 20161021 04:59:54< vultraz> tad_carlucci: then reverting the canvas changes which would result in a loss of the small performance gain it gave.. 20161021 04:59:57< celticminstrel> Hmm, did HTTT and SoF not use flipx_chance or flipy_chance? 20161021 04:59:59< vultraz> tad_carlucci: I do not find this viable 20161021 05:01:16< celticminstrel> "transpose" is "flip acros y=-x", right...3 20161021 05:01:20< celticminstrel> ^across 20161021 05:01:23< tad_carlucci> vultraz, So it's too costly in the one-time-costs of falling back. OK. Then how about iceiceice's idea of hosting the packages so it's click, run, click, run from our site? 20161021 05:01:39< vultraz> tad_carlucci: I have no objections 20161021 05:01:44< iceiceice> tad_carlucci, i think that might only be worth it for things like boost though 20161021 05:01:52< iceiceice> where it takes a huge amount of time to compile 20161021 05:02:01< iceiceice> with sdl2 i think the compile time is actually close to teh download time 20161021 05:02:07< vultraz> boost doesn't take long to build :P 20161021 05:02:08< iceiceice> i mean u could mak ea ppa if u want 20161021 05:02:36< iceiceice> i think i would try just doing it with a shell-script as part of preinstall in travis before trying to make a ppa 20161021 05:02:40< iceiceice> and then go to ppa if that is too slow 20161021 05:03:02< tad_carlucci> iceiceice, But if we can spoon feed the users with a pre-baked Linux .so library that's way faster. 20161021 05:03:04< iceiceice> u could probably cache the built lib also 20161021 05:03:20< tad_carlucci> Well, I have to go. 20161021 05:03:22< iceiceice> tad_carlucci, are you talking about travis-ci or like, other developers? 20161021 05:03:24< vultraz> keep in mind I can't do any of this 20161021 05:03:30< vultraz> I'm not on linux :P 20161021 05:03:42< tad_carlucci> iceiceice, I'm talking end users 20161021 05:03:49< iceiceice> o ic 20161021 05:04:01< tad_carlucci> Travis is solvable. Just takes work. 20161021 05:04:25< tad_carlucci> I need to go. The wife beckoneth. 20161021 05:04:29-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Switching to Unix to get some real work done.] 20161021 05:11:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20161021 05:16:37-!- irker958 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161021 05:19:54< zookeeper> celticminstrel, gfgtdf, why the old cave generator didn't use terrains like rockbound cave? because when it was written, that kind of terrain didn't exist, i'd imagine. 20161021 05:46:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 05:48:38< celticminstrel> for i,tag in ipairs(chamber_items) table.insert(scenario, tag) end 20161021 05:48:48< celticminstrel> ^ That's the way to append all tags from one config to another config, right? 20161021 05:50:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 245 seconds] 20161021 05:52:47-!- irker296 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161021 05:52:47< irker296> wesnoth: Celtic Minstrel wesnoth:lua_mapgen_stuff 0c2529e46e51 / data/lua/cave_map_generator.lua: Lua Cave Mapgen: Support [chamber]chance= https://github.com/wesnoth/wesnoth/commit/0c2529e46e5101c6b54af21e27ecc94286eb1221 20161021 05:52:47< irker296> wesnoth: Celtic Minstrel wesnoth:lua_mapgen_stuff d376371faff3 / data/ (4 files in 3 dirs): Lua Cave Mapgen: Support random chance of flipping the map https://github.com/wesnoth/wesnoth/commit/d376371faff363817b05adf59932a92c0f5d297e 20161021 05:52:48< irker296> wesnoth: Celtic Minstrel wesnoth:lua_mapgen_stuff bcddcb6b7790 / data/lua/cave_map_generator.lua: Lua Cave Mapgen: Support scenario generation https://github.com/wesnoth/wesnoth/commit/bcddcb6b779019ecc41b4dcd627fb50aaa93c8e7 20161021 05:53:08< celticminstrel> Now I just have to do user config. Though I'd like to add a few other features too. 20161021 05:53:39-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161021 05:53:41< celticminstrel> I'd also like to add an MP cave random map, but does anyone think this is a bad idea? I'm not sure how suitable the generator is for MP maps right now. 20161021 05:56:09-!- skeletenchi [enchilado@defocus/yummy/enchilado] has quit [Remote host closed the connection] 20161021 05:57:32< celticminstrel> On the other hand, the sort of new features I'm thinking of might make it more suitable. 20161021 06:09:05-!- skeletenchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev 20161021 06:10:04-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev 20161021 06:36:21-!- higgins [~higgins@68.ip-149-56-14.net] has quit [Ping timeout: 248 seconds] 20161021 06:36:27< vultraz> you can generate a cave map in mp 20161021 06:36:29< vultraz> what's wrong with it 20161021 06:37:13-!- travis-ci [~travis-ci@ec2-54-80-28-96.compute-1.amazonaws.com] has joined #wesnoth-dev 20161021 06:37:14< travis-ci> wesnoth/wesnoth#11684 (lua_mapgen_stuff - bcddcb6 : Celtic Minstrel): The build has errored. 20161021 06:37:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/169445514 20161021 06:37:14-!- travis-ci [~travis-ci@ec2-54-80-28-96.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161021 06:37:48-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: Going offline for a moment] 20161021 06:38:17-!- higgins [~higgins@68.ip-149-56-14.net] has joined #wesnoth-dev 20161021 06:41:05< vultraz> celticminstrel: 20161021 06:48:09-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev 20161021 07:21:48-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev 20161021 07:25:47< Rhonda> Aginor: Well, Debian oldstable has 4.6 on some, 4.7 on others. I don't think we should limit us to old stable/lts releases. And that's with my Debian/Ubuntu hat on. :) 20161021 07:28:01< Rhonda> Aginor: And it's not like we are pulling the old wesnoth releases from there. We are talking about the future versions, not the current ones, right? My standing is that we can safely assume that Debian stable and Ubuntu current LTS are the oldest we should consider for future development. 20161021 07:31:51< Rhonda> I see that tad_carlucci is a fine person with not showing clear lack of knowledge about what PPA is and throwing around statements that are clearly proven utterly wrong. :) 20161021 07:34:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 07:39:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds] 20161021 07:47:19< vultraz> Rhonda: debian stable and ubuntu current lts is what I'm advocating, yes. glad you agree. 20161021 07:47:20< vultraz> :) 20161021 07:51:07-!- boucman_work [~boucman@74.105.204.77.rev.sfr.net] has joined #wesnoth-dev 20161021 07:52:41< Rhonda> Well, ubuntu current as in LTS release, but yes. 20161021 07:53:34< vultraz> which means there's no reason to continue supporting trusty 20161021 07:53:45< vultraz> but how to point travis at xenial :/ 20161021 07:54:42< Rhonda> What's travis? 20161021 07:55:29< vultraz> the buildbot 20161021 08:02:47< shadowm> https://github.com/travis-ci/travis-ci/issues/5821 20161021 08:03:29< shadowm> tl;dr is apparently you can by using Docker (never used it, don't ask me) and sacrificing job times. 20161021 08:03:39< shadowm> And otherwise you can't. 20161021 08:04:05< vultraz> Heh, I had just found that page myself 20161021 08:05:20< celticminstrel> vultraz: The generator doesn't have much customization and is poorly suited to generating maps with an unknown number of sides. 20161021 08:05:48< celticminstrel> Also, quite frankly, I think the maps it generates at present would be rather boring. 20161021 08:05:56< celticminstrel> It's basically one terrain type. 20161021 08:06:13< celticminstrel> (That's why I wanted to add some more features, to make it able to generate more interesting maps.) 20161021 08:06:26-!- celticminstrel is now known as celmin|sleep 20161021 08:10:40< shadowm> vultraz: I read that you want to implement a window manager/tracker for GUI2? 20161021 08:45:00-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has quit [Ping timeout: 250 seconds] 20161021 09:00:46-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .] 20161021 09:07:24-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai] 20161021 09:07:47-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 09:08:11-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit] 20161021 09:08:37-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 09:08:59-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit] 20161021 09:09:22-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 09:09:47-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit] 20161021 09:10:11-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 09:10:35-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit] 20161021 09:11:01-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 09:11:16-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20161021 09:11:23-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit] 20161021 09:11:48-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 09:12:11-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit] 20161021 09:21:18-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev 20161021 09:22:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 09:27:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20161021 10:03:48-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 256 seconds] 20161021 10:09:11-!- irker296 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161021 10:11:20-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .] 20161021 10:50:01-!- esr [~esr@wesnoth/developer/esr] has quit [Quit: WeeChat 1.4] 20161021 10:52:42-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev 20161021 10:52:42-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host] 20161021 10:52:42-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev 20161021 11:11:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 11:12:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 11:14:04-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20161021 11:14:11-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev 20161021 11:15:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds] 20161021 12:27:22< vultraz> shadowm: what do you mean? 20161021 12:29:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 12:29:53-!- gfgtdf [~chatzilla@x4e368475.dyn.telefonica.de] has joined #wesnoth-dev 20161021 12:31:18< vultraz> shadowm: all I implemented recently was a window stack vector. Any open and displayed window keeps a pointer there. I have yet to expand it into anything further. 20161021 12:33:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20161021 12:44:38-!- Bonobo [~Bonobo@2001:44b8:254:3200:f82b:1118:8096:6cd2] has quit [Ping timeout: 245 seconds] 20161021 12:53:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds] 20161021 12:54:08-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20161021 13:00:17-!- higgins [~higgins@68.ip-149-56-14.net] has quit [Remote host closed the connection] 20161021 13:04:48-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20161021 13:08:38-!- Appleman1234_ [~Appleman1@KD106181173238.au-net.ne.jp] has joined #wesnoth-dev 20161021 13:11:02-!- Appleman1234 [~Appleman1@KD106154015081.au-net.ne.jp] has quit [Ping timeout: 252 seconds] 20161021 13:19:40-!- higgins [~higgins@68.ip-149-56-14.net] has joined #wesnoth-dev 20161021 13:22:46-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161021 13:26:44-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20161021 13:33:36-!- Shiki [~Shiki@141.57.57.59] has joined #wesnoth-dev 20161021 13:33:44-!- Shiki is now known as shiki|sevu 20161021 13:44:27-!- shiki|sevu [~Shiki@141.57.57.59] has quit [Quit: Verlassend] 20161021 13:48:13-!- boucman_work [~boucman@74.105.204.77.rev.sfr.net] has quit [Ping timeout: 256 seconds] 20161021 13:50:39-!- boucman_work [~boucman@194.195.204.77.rev.sfr.net] has joined #wesnoth-dev 20161021 13:54:43-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .] 20161021 13:58:59-!- clavii [~clavi@163-172-10-77.rev.poneytelecom.eu] has joined #wesnoth-dev 20161021 14:01:08-!- clavi [~clavi@163-172-10-77.rev.poneytelecom.eu] has quit [Ping timeout: 260 seconds] 20161021 14:04:59< vultraz> i wonder if i make addon downloads happen in-manager, that should be threaded. 20161021 14:08:34< vultraz> loonycyborg: how much work would it be to delegate the network process to a separate thread? 20161021 14:09:42< loonycyborg> vultraz: You sure you absolutely need threads there? 20161021 14:10:09< loonycyborg> a simpler way would be 20161021 14:10:30< loonycyborg> have gui poll asio event loop at each redraw 20161021 14:10:41< loonycyborg> that way you'd have no thread 20161021 14:10:48< loonycyborg> and no possible synchronization issues 20161021 14:12:07< vultraz> I see 20161021 14:12:54< vultraz> I suppose the network process would not be interrupted by gui handling would it 20161021 14:13:00-!- prkc [~prkc@catv-89-133-39-230.catv.broadband.hu] has quit [Ping timeout: 244 seconds] 20161021 14:13:41-!- DeFender1031 [~DeFender1@46-116-17-86.bb.netvision.net.il] has quit [Quit: I'm not back now.] 20161021 14:15:59-!- clavii is now known as clavi 20161021 14:18:59< loonycyborg> interrupted how? 20161021 14:19:12-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 244 seconds] 20161021 14:19:40< loonycyborg> network operations will have no effect on observable state, other than things done by handlers that are called when polling 20161021 14:20:19< vultraz> ok, got it. 20161021 14:26:24-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev 20161021 14:33:27-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20161021 14:45:13-!- aeth_ [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev 20161021 14:45:20-!- edgrey [~edgrey@178.204.130.234] has joined #wesnoth-dev 20161021 14:47:01-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 248 seconds] 20161021 14:48:01-!- edgrey [~edgrey@178.204.130.234] has left #wesnoth-dev [] 20161021 15:02:20-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 265 seconds] 20161021 15:04:31-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20161021 15:07:22-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev 20161021 15:16:05-!- boucman_work [~boucman@194.195.204.77.rev.sfr.net] has quit [Ping timeout: 260 seconds] 20161021 15:27:53-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20161021 15:28:40-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161021 15:41:16< mattsc> I have a question for those of you who actually understand coding (and Lua). In this line: 20161021 15:41:17< mattsc> https://github.com/wesnoth/wesnoth/blob/master/data/ai/lua/ai_helper.lua#L1008 20161021 15:41:56< mattsc> I figured that ‘side’ is a local variable, as it is one of the parameters passed to the function. 20161021 15:42:37< mattsc> However, in one of the MAI test scenarios, I have two sides who both call this function, and both do not pass the ‘side’ parameter. 20161021 15:42:50< vultraz> side is not local 20161021 15:42:51< mattsc> I would have expected it therefore to default to the current side. 20161021 15:42:59< vultraz> it's reassigning one of the function arguments 20161021 15:43:04-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has joined #wesnoth-dev 20161021 15:43:34< Soliton> a function argument is fairly local. 20161021 15:43:35< vultraz> if side is false then it's wesnoth.viewing_side 20161021 15:43:45< vultraz> er 20161021 15:43:46< mattsc> Right, but I … ^ as Soliton says 20161021 15:43:48< vultraz> current_side 20161021 15:44:17< mattsc> vultraz: yes, I know, I wrote that code. Let me finsih what I am trying to say. 20161021 15:45:23< mattsc> [ And I also know that if it is a table and you modify it, then the input table gets modified; however, I thought that if it’s a number, it gets turned into a local variable inside that function. ] Anyways: 20161021 15:45:52< mattsc> So I use this in the AIs of two sides, neither of which passes the argument. 20161021 15:46:07< mattsc> For the first side, this works just fine and it chooses the local side for ‘side'. 20161021 15:46:31< mattsc> However, when I call it for the second time, it remembers the value from the previous side, and uses that. 20161021 15:46:41< mattsc> That is contrary to my understanding of how this should work. 20161021 15:46:53< mattsc> So the question is, is my understanding wrong or is this a bug. 20161021 15:46:58< mattsc> [now I am done] 20161021 15:47:07-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev 20161021 15:47:14-!- Shiki is now known as shiki|sevu 20161021 15:47:34< gfgtdf> mattsc: so when you remove its use in the first side, the secod side work again ? 20161021 15:48:11< mattsc> gfgtdf: I am sure that that is the case, yes, but I haven’t actually tired it. Let me do that quickly. 20161021 15:49:06< mattsc> gfgtdf: yes, tried it 20161021 15:49:33< mattsc> So what happens is that Lua somehow remembers the value from the AI from the first side, and reuses it for the next. 20161021 15:49:40< mattsc> As I side, that’s not how I thought it should work. 20161021 15:49:58< mattsc> *As I said 20161021 15:54:03< mattsc> I also know that I can work around this using ‘local local_side = side or wesnoth.current.side’, but I thought that (scalar) function parameters were local variables already, so I didn’t need to do that. 20161021 15:56:39< Soliton> a simple online test works as expected: function fun(a, b, c) b = b or "b"; print(a, b); end; fun(1,2); fun(1); outputs '1 2' and '1 b' as expected. 20161021 15:57:38-!- EliDupree2 [~quassel@2604:a880:400:d0::9bb:2001] has quit [Remote host closed the connection] 20161021 15:59:05< mattsc> Soliton: Yeah, I am certain that I have used this before and that it worked as expected. 20161021 15:59:48< mattsc> I just this morning noticed that one of the AIs in a test scenario is not behaving as it should. 20161021 16:00:00< Soliton> just saying that it's not a vanilla lua thing. must be some wesnoth (ai) specific caching or so. 20161021 16:00:19< mattsc> Soliton: right, understood 20161021 16:01:40< Soliton> what does wesnoth.current.side yield when you call it explicitly? 20161021 16:03:06< mattsc> The correct side number in all cases. The problem is not due to wesnoth.current.side, but the fact that ‘side’ is not nil. 20161021 16:03:12< Soliton> maybe there is also a global side that somehow gets precedence over the local side? (seems unlikely) 20161021 16:03:42< gfgtdf> do you also have prbplems connecting to github.com ? 20161021 16:04:31< mattsc> gfgtdf: no (I can get to the website just fine, if that’s what you mean) 20161021 16:04:49< Soliton> http://www.isup.me/github.com 20161021 16:05:11< gfgtdf> hmm ok 20161021 16:05:15< Soliton> i just got a network error myself now though. 20161021 16:05:28< gfgtdf> Soliton: form github ? 20161021 16:05:35< Soliton> yes. 20161021 16:05:54< mattsc> Soliton: that’s an interesting idea, I can check that easily 20161021 16:06:07< Soliton> (not the main page but by refreshing the link mattsc posted earlier.) 20161021 16:07:02< gfgtdf> mattsc: if you want to test wesnoth.current.side you could try replacing it with wesnoth.get_variable("side") 20161021 16:07:32< mattsc> gfgtdf: as I said, wesnoth.current.side is not the problem, that works just fine 20161021 16:08:18-!- gfgtdf [~chatzilla@x4e368475.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]] 20161021 16:08:43< mattsc> Soliton: no, that’s not the problem; I renamed the ‘side’ variable and am getting the same result 20161021 16:08:50-!- gfgtdf [~chatzilla@x4e368475.dyn.telefonica.de] has joined #wesnoth-dev 20161021 16:09:42< mattsc> gfgtdf: the problem is that the ‘side’ parameter remains set from a previous AI/side if it is not passed explicitely to the function. 20161021 16:09:52< Soliton> yep, my test also failed: https://repl.it/ECs0/1 20161021 16:11:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 16:11:52-!- EliDupree [~quassel@2604:a880:400:d0::9bb:2001] has joined #wesnoth-dev 20161021 16:15:42< gfgtdf> mattsc: did you do any change to the lua file that are not in master ? 20161021 16:17:37< gfgtdf> mattsc: also did you test that using that wunction with passin the secodn parameter explictly 'fixes' your isue? 20161021 16:18:25< mattsc> gfgtdf: yes, I have some pending commits in the ai_helper file, but none of it is in this function. 20161021 16:18:36< mattsc> and yes on your second question, that does fix it 20161021 16:21:11< mattsc> gfgtdf: hmm, I just commited those changes, but irker seems to be absent. 20161021 16:21:39< mattsc> In any case, now my local version and master are the same (except for some debug code I added to figure out what is going on here). 20161021 16:24:00-!- irker976 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161021 16:24:00< irker976> wesnoth: mattsc wesnoth:master 022d2cd72591 / data/ai/lua/ai_helper.lua: ai_helper checked actions: some modifications to error messages https://github.com/wesnoth/wesnoth/commit/022d2cd725914cead8a70005564c477413c5a0e3 20161021 16:24:00< irker976> wesnoth: mattsc wesnoth:master 204ccb058447 / data/ai/lua/ai_helper.lua: ai_helper: move checks for incomplete/empty moves to functions https://github.com/wesnoth/wesnoth/commit/204ccb058447128a74061cbe7425b67b0cd7fa50 20161021 16:24:00< irker976> wesnoth: mattsc wesnoth:master 13d2cdfc299f / data/ai/lua/ai_helper.lua: ai_helper checked actions: return action result to calling function https://github.com/wesnoth/wesnoth/commit/13d2cdfc299fcd7cb0d74d5c44a20037f532e64f 20161021 16:24:01< irker976> wesnoth: mattsc wesnoth:master 74792845d75c / data/ai/lua/ai_helper.lua: ai_helper.movefull_stopunit: return action result to calling function https://github.com/wesnoth/wesnoth/commit/74792845d75ce172a103575e598403a952ba80f0 20161021 16:24:02< irker976> wesnoth: mattsc wesnoth:master 348f64f4a01e / data/ai/micro_ais/cas/ca_wolves_multipacks_wander.lua: Multipack Wolves Micro AI: better recovery from ambushes etc. https://github.com/wesnoth/wesnoth/commit/348f64f4a01e4a39e88f3f6fec5f8f7149a3c58f 20161021 16:24:04< irker976> wesnoth: mattsc wesnoth:master 67fd4367fd5d / data/ai/micro_ais/cas/ (ca_wolves_move.lua ca_wolves_wander.lua): Wolves Micro AI: better recovery from ambushes etc. https://github.com/wesnoth/wesnoth/commit/67fd4367fd5de28aabfb9f43c6a21a4ebcfd73ba 20161021 16:24:23< mattsc> Oh, there we go. irker’s just slow. 20161021 16:24:51-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind] 20161021 16:25:16< Soliton> gfgtdf: github works again for me now. 20161021 16:27:34< gfgtdf> yes for me too 20161021 16:32:02< tad_carlucci> mattsc, You're good on PR 836? Someone want to merge it? 20161021 16:33:23< mattsc> tad_carlucci: yes, it fixes the crash for me (I added a comment on the github page). 20161021 16:37:20-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai] 20161021 16:37:23< vultraz> tad_carlucci: good to merge? 20161021 16:37:35< mattsc> tad_carlucci: I can merge it, but somebody else needs to tell me that it is okay to do so. (I can only say that it fixes the panic, not whether it has other effects) 20161021 16:37:43< mattsc> or vultraz can 20161021 16:39:09-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20161021 16:39:09-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20161021 16:39:10< tad_carlucci> vultraz, Push the button. I was 100% positive it would do the trick and have no side effects the moment I found it; just wanted mattsc to confirm it clears the panic. 20161021 16:41:23< vultraz> tad_carlucci: ok, gh seems to have screwed up... pressed merge, gave me an error, but it seems to have merged anyway w/o reporting 20161021 16:41:45< vultraz> So I'm closing the PR. that change's in the repo. 20161021 16:42:17< vultraz> the* 20161021 16:43:38 * tad_carlucci nods. 20161021 16:45:24< tad_carlucci> Yeah. I'm thinking the DDoS against Level 3's DYN nameservers or something similar out west. 20161021 16:45:34< vultraz> whut 20161021 16:47:17< tad_carlucci> The github issues. Loonngg time to resolve host. Pages timed out as a result. Feels like the DDoS against the east coast name servers still going on or moving west. 20161021 16:48:07< vultraz> there's a ddos? 20161021 16:48:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 16:50:13< mattsc> gfgtdf, Soliton: with the ‘side’ problem I reported, there’s something strange going on here, because it works for all other sides in the test scenario (there are 7 total) except for the wolves. 20161021 16:50:25< tad_carlucci> Against Level3. If you want a link I can find one. Was big news a few hours ago. 20161021 16:50:31< mattsc> So my guess is that I have a subtle bug in the AI code somewhere. 20161021 16:51:06< mattsc> I don’t have time to deal with it right now, but I’ll check it out later. It looks like it’s a problem for me to solve though. If not, I’ll raise the alarm again later. 20161021 16:52:38< mattsc> Ah, crap, found it already ... 20161021 16:52:55 * Soliton is curious. 20161021 16:53:02< mattsc> I didn’t know that helper.get_child returns two arguments. :P 20161021 16:53:21< Soliton> ah, so you actually did specify the parameter? 20161021 16:53:39< mattsc> So this is the offending line: https://github.com/wesnoth/wesnoth/blob/master/data/ai/micro_ais/cas/ca_wolves_move.lua#L14 20161021 16:53:48< mattsc> Soliton: yes, inadvertently 20161021 16:54:27< mattsc> Well, I’m glad it’s that simple. Sorry for wasting everybody’s time. :\ 20161021 16:55:03-!- shiki|sevu [~Shiki@141.39.226.226] has quit [Ping timeout: 245 seconds] 20161021 16:55:23< mattsc> I’ll check tonight that I don’t have other places where I do this too and then fix this. 20161021 16:56:12< gfgtdf> matts: maybe get_child() returns 2 values ? 20161021 16:56:34< mattsc> gfgtdf: yes, it does. (Isn’t that what I just said?) 20161021 16:56:53< gfgtdf> mattsc;: didnt read xompleteley just saw te link 20161021 16:56:56< mattsc> Ah, sorry, I said arguments, not values 20161021 16:57:02< gfgtdf> completeley* 20161021 16:57:14< mattsc> gfgtdf: yes, it does and the fix is super simple of course 20161021 16:59:57< gfgtdf> mattsc: but thne i wonder how this removing the side 1 ai code ai side could fix the side 2 ai 20161021 17:00:33< Soliton> presumably that was just a wrong conclusion. 20161021 17:00:39< mattsc> gfgtdf: yeah, well, I hope you wouldn’t ask that, because I messed up the test. It doesn’t (I retested) 20161021 17:00:47< mattsc> *hoped 20161021 17:01:50-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20161021 17:02:34< gfgtdf> ok 20161021 17:07:57-!- shiki|sevu [~Shiki@141.39.226.226] has joined #wesnoth-dev 20161021 17:17:26< celmin|sleep> Blargh, can't get to github... 20161021 17:17:29-!- celmin|sleep is now known as celticminstrel 20161021 17:18:52-!- karthago [~edgrey@178.204.130.234] has joined #wesnoth-dev 20161021 17:19:27< tad_carlucci> www.theatlantic.com/technology/archive/2016/10/when-the-entire-internet-seems-to-break-at-once/504956/ 20161021 17:20:14-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 17:22:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 256 seconds] 20161021 17:24:23-!- stikonas_ is now known as stikonas 20161021 17:29:04-!- travis-ci [~travis-ci@ec2-54-166-138-194.compute-1.amazonaws.com] has joined #wesnoth-dev 20161021 17:29:05< travis-ci> wesnoth/wesnoth#11686 (master - 67fd436 : mattsc): The build has errored. 20161021 17:29:05< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/169579894 20161021 17:29:05-!- travis-ci [~travis-ci@ec2-54-166-138-194.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161021 17:34:13< tad_carlucci> Looks like AWS is having trouble talking to GitHub, too. 20161021 17:34:52< celticminstrel> AWS? 20161021 17:37:14< tad_carlucci> Amazon Web Services. Travis-CI 20161021 17:37:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161021 17:37:32-!- karthago [~edgrey@178.204.130.234] has quit [Quit: Konversation terminated!] 20161021 17:37:57-!- edgrey [~edgrey@178.204.130.234] has joined #wesnoth-dev 20161021 17:38:26-!- karthago [~edgrey@178.204.130.234] has joined #wesnoth-dev 20161021 17:41:29-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161021 17:45:52-!- 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.] 20161021 17:46:40-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161021 18:00:08< tad_carlucci> github:status UPDATED ABOUT AN HOUR AGO 20161021 18:00:08< tad_carlucci> 11:36 Central Daylight TimeWe are investigating DNS resolution issues for GitHub.com. 20161021 18:00:39-!- shiki|sevu [~Shiki@141.39.226.226] has quit [Remote host closed the connection] 20161021 18:08:26-!- edgrey [~edgrey@178.204.130.234] has quit [Quit: Konversation terminated!] 20161021 18:08:46-!- edgrey [~edgrey@178.204.130.234] has joined #wesnoth-dev 20161021 18:08:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161021 18:09:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 18:18:30< gfgtdf> celticminstrel: i wonder what exactly is the intention fpor supporting scenario_generation= in the lua cavegen? it is just for backwards compability or do you have cases where it's actually better to use scenario_generation= over map_generation= ? 20161021 18:19:19< celticminstrel> I think you're misunderstanding something. The Lua generator already supports scenario generation. 20161021 18:19:40< celticminstrel> So it seems reasonable to make the cave generator able to produce scenarios. 20161021 18:19:57< celticminstrel> Anyway, backwards compatibility is certainly one concern. 20161021 18:20:34< celticminstrel> And I believe there are use-cases for using scenario generation instead of map generation. Specifically, you might want events associated with an optional chamber. 20161021 18:20:53< celticminstrel> With scenario generation you can avoid those events appearing in the scenario if the chamber is not even generated. 20161021 18:21:25< celticminstrel> With map generation you'd need to have them in the scenario no matter what, just referencing a location_id that may or may not exist. 20161021 18:21:39< gfgtdf> celticminstrel: if it not for backwarsd compoabiliti suggest ot rename [setttings] to [scenario] to be consitent with te default magen syntax. 20161021 18:22:28< celticminstrel> Well, it's partly for backwards compatibility, but... I don't particularly intend for it to be fully compatible with the old cave generator. I'm going more for feature parity. 20161021 18:23:00< celticminstrel> So sure, I can change the tag name. If I'm doing that I should probably change [items] to something else too, any suggestions? 20161021 18:24:09< gfgtdf> celticminstrel: hmm i don't see problems with [items] 20161021 18:25:58< gfgtdf> celticminstrel: you intend to rmeove the c++ implementation after that ? 20161021 18:28:18< celticminstrel> Uh. No? 20161021 18:29:34< celticminstrel> I guess it can be removed after 1.14. 20161021 18:31:31< gfgtdf> tad_carlucci: you have any idea what coudl go wrong in http://gna.org/bugs/?25194 ? there is a crash inside lua_pushglobaltable() after a getting an erros from a [lua] in [scenario] 20161021 18:32:03< celticminstrel> Is it fixed by his PR that was supposedly merged? 20161021 18:32:04< tad_carlucci> Let me look into it. 20161021 18:32:05< gfgtdf> tad_carlucci: (actuall there arew differnt isues involved in that report, ignore teh rason why it crashes for now) 20161021 18:32:20< gfgtdf> celticminstrel: don't think so, since its unrelated t ai code 20161021 18:32:25< tad_carlucci> celticminstrel, yes it actually merged. 20161021 18:32:27< celticminstrel> Ah, good point. 20161021 18:32:39< celticminstrel> tad_carlucci: Well, I can't tell since I can't get to github. 20161021 18:33:00< tad_carlucci> celticminstrel, it's spotty here and I'm only a few hops away. 20161021 18:33:48< gfgtdf> tad_carlucci: wait it actuall a lua erros in a preload event handler 20161021 18:34:21< tad_carlucci> gfgtdf, Have matthiaskrgr sync to master and retest. It's possible my PR just merged will fix it. 20161021 18:34:51< gfgtdf> matthiaskrgr: ^ 20161021 18:34:53< celticminstrel> Crash when trying to load a map in the editor... :( 20161021 18:34:55< tad_carlucci> Meanwhile I'll see if I can reproduce it once the build-tests I'm running finish. Maybe an hour or two 20161021 18:36:29< tad_carlucci> I'm doing a hard clean (rm -fR) and make all to ensure clean compiles at strict level. Unix clang and gcc passed. VC14 is building and passing so far. 20161021 18:42:01-!- aeth_ is now known as aeth 20161021 18:48:28< tad_carlucci> gfgtdf, Actually, looks like a typo. Don't know the reference but it's spelled wrong. wesnoth.get_variable("enemey_gold_factor") 20161021 18:48:45< tad_carlucci> matthiaskrgr, ^ 20161021 18:49:15< gfgtdf> tad_carlucci: thats not the cause, its speeles the same way on the other part 20161021 18:49:23< gfgtdf> tad_carlucci: and even it it shoduln crash the application 20161021 18:49:30< gfgtdf> tad_carlucci: even then* 20161021 18:49:46< tad_carlucci> That would be the nil reference math error, though. 20161021 18:50:16< gfgtdf> tad_carlucci: yes but still it shoudlnt result in "heap-buffer-overflow on address 0x6170001c8c70 at pc 0x000005cbd73c bp 0x7ffcacbd32a0 sp 0x7ffcacbd3290" 20161021 18:50:56< tad_carlucci> I'll see. It's possible that it threw a lua error and my patch would then kick in. I'll run some tests once my CPU isn't so busy. 20161021 18:50:58< gfgtdf> tad_carlucci: we know that that lua code erro becasue of "assigning to performa arethmetic on a nil value" eg.g that variable is not set, but we dont know why this causes a heap-buffer-overflo 20161021 18:51:53< tad_carlucci> The stack corruption I fixed in that PR might be the fix. I'll check when I can. An hour or so. 20161021 18:53:37< gfgtdf> tad_carlucci: hmm i thought your change only effects ai-related erros since te file batches is in src/ai/lua/ 20161021 18:55:29< tad_carlucci> OK. Well, it was coming back from a pcall. So it's possible we have another issue with the stack. I'll get to it. Actually .. thanks .. I'm just waiting for 1.13.6 to tag and this gives me something productive to do. 20161021 18:57:26< celticminstrel> So the file dialog is crashing... :( 20161021 18:57:41< celticminstrel> In icompare. 20161021 19:07:38-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20161021 19:12:17-!- tad_carlucci_ [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161021 19:12:28-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Switching to Unix to get some real work done.] 20161021 19:12:42-!- tad_carlucci_ is now known as tad_carlucci 20161021 19:16:36< tad_carlucci> gfgtdf, I an on current master and can reproduce the crash. 20161021 19:20:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 19:24:21-!- irker976 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161021 19:24:22-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 19:24:49-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit] 20161021 19:26:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds] 20161021 19:29:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161021 19:52:32-!- edgrey [~edgrey@178.204.130.234] has quit [Quit: Konversation terminated!] 20161021 19:59:24< gfgtdf> tad_carlucci: ok 20161021 19:59:32< gfgtdf> tad_carlucci: you hve an idea what teh cause coudl be? 20161021 20:00:47< shadowm> celticminstrel: Do you have any more information about the icompare crash? 20161021 20:01:48< tad_carlucci> gfgtdf, Lua function ipairs(). Might be a problem with Lua 5.3.3 .. I'm working it. 20161021 20:07:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 20:09:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host] 20161021 20:09:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 20:24:20< celticminstrel> Well, it's in isort_dir_entries... I could probably paste a stack trace somewhere... 20161021 20:24:42< celticminstrel> The Boost collator is segfaulting for some reason. 20161021 20:28:40< celticminstrel> All I did was open the map editor and click the load map button. 20161021 20:29:16< celticminstrel> It crashes when sorting the subdirs but not when sorting the file entries... 20161021 20:30:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 20:30:27-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev 20161021 20:32:07< celticminstrel> http://pastebin.com/ZDsDjuc9 20161021 20:32:44< celticminstrel> Oh, looks like github's back. 20161021 20:33:47< aeth> It was never down, it was just made inaccessible for a lot of people. 20161021 20:33:54< celticminstrel> Close enough. 20161021 20:34:07< aeth> I use Google's DNS (8.8.8.8) and I never noticed Twitter or Github being down. 20161021 20:34:16< aeth> Apparently 8.8.8.8 didn't work in all areas of the world, though. 20161021 20:34:27< celticminstrel> I thought I was using Google too... I guess not on this computer. 20161021 20:34:34< aeth> I set it at the router level 20161021 20:36:07< tad_carlucci> *** Error in `/home/lundberg/wesnoth/wesnoth': corrupted double-linked list: 0x00007f9008c45d10 *** 20161021 20:36:07< tad_carlucci> ======= Backtrace: ========= 20161021 20:36:23< tad_carlucci> Huh? 20161021 20:38:25< aeth> celticminstrel: you might have been using Google DNS, though. Some comments said it didn't work 20161021 20:39:50< celticminstrel> Looks like this computer is set to use the router for DNS. 20161021 20:40:06< celticminstrel> I think my phone is set to use Google. 20161021 20:40:25-!- irker752 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161021 20:40:25< irker752> wesnoth: gfgtdf wesnoth:master 2f6bb71b8286 / src/teambuilder.cpp: improve error message in case of an invalid unittype in [side] https://github.com/wesnoth/wesnoth/commit/2f6bb71b82866c016bb7c1448c76681a4fe9ff11 20161021 20:55:04< mattsc> celticminstrel: why not? 20161021 20:56:19< celticminstrel> Well, the argument is supposed to be an error message, so to omit that seems weird. 20161021 20:57:14< mattsc> the line before gives the error message 20161021 20:57:26< mattsc> the error() call is only there to give the stacktrace 20161021 20:57:46< celticminstrel> Then why not just use error() and not wesnoth.message()? 20161021 20:57:54< celticminstrel> The message in error() still goes to chat, doesn't it? 20161021 20:58:59< mattsc> It does, yes. 20161021 20:59:50< mattsc> The reason why I did it is because wesnoth.message gives me a separate string for the … “title” of the message, or whatever it’s called. “speaker” 20161021 20:59:59< mattsc> I guess that’s not really a good argument ... 20161021 21:00:33< celticminstrel> I see. 20161021 21:00:40< mattsc> Well, I guess the real reason is because those were two separate messages originally and I just didn’t change it. 20161021 21:00:48< celticminstrel> Well, it's an argument, but... 20161021 21:00:57< mattsc> right 20161021 21:01:16< mattsc> I can move it into error() and add the ‘Lua AI error’ to the string. That’s fine by me. 20161021 21:01:43< celticminstrel> What's the speaker string then? 20161021 21:01:57< celticminstrel> "Lua error" or something? 20161021 21:02:51< mattsc> yes “Lua AI error” 20161021 21:03:05< mattsc> I’l put it into the error() call, no problem 20161021 21:03:06< celticminstrel> No I mean, when error() is used. 20161021 21:03:15< celticminstrel> There's still a speaker string IIRC. 20161021 21:03:19< mattsc> Oh ... 20161021 21:03:20< celticminstrel> It's just not customizable. 20161021 21:03:34< mattsc> it’s something more “complicated”, don’t remember right now 20161021 21:03:37< mattsc> right 20161021 21:07:51< mattsc> This is how it looks then (I just hacked ‘xxx’ as error message into the call to error() for now}: 20161021 21:07:56< mattsc> “error scripting/lua: When executing, Lua runtime error: ai/lua/ai_helper.lua:173: xxx” 20161021 21:08:29< mattsc> It’s just not as “neat” as when it only says “ xxx” 20161021 21:08:40< celticminstrel> Oh, there's actually no speaker string then? 20161021 21:08:50-!- travis-ci [~travis-ci@ec2-54-205-74-4.compute-1.amazonaws.com] has joined #wesnoth-dev 20161021 21:08:51< travis-ci> wesnoth/wesnoth#11687 (master - 2f6bb71 : gfgtdf): The build failed. 20161021 21:08:52< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/169616745 20161021 21:08:52-!- travis-ci [~travis-ci@ec2-54-205-74-4.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161021 21:09:11< mattsc> Ah, no, hmm, you’re right. That’s what it says in stderr 20161021 21:09:59< mattsc> ai/lua/ai_helper.lua:173: xxx 20161021 21:11:14< irker752> wesnoth: gfgtdf wesnoth:master 15afec7202ae / src/teambuilder.cpp: fixup 'improve error message in case of an invalid unittype in [side]' https://github.com/wesnoth/wesnoth/commit/15afec7202aec46d952f23f49224652601ffe8f5 20161021 21:15:16< celticminstrel> gfgtdf: If you're editing on github I recommend using a PR instead of committing directly to master. Then you can squash and merge once it works. 20161021 21:15:51< celticminstrel> mattsc: Uh... that seems like a very poor choice... 20161021 21:15:57< celticminstrel> Who came up with that... 20161021 21:16:02< celticminstrel> ...not that it matters who. 20161021 21:16:17< mattsc> Right. 20161021 21:19:57< celticminstrel> Hmm, so it's in lua_kernel_base::protected_call... 20161021 21:20:23< celticminstrel> I think it would make more sense for that text to be part of the error string, and just use "Lua Error" as the "speaker". 20161021 21:25:10< mattsc> Sounds good to me 20161021 21:26:02< tad_carlucci> UI Bug. In MP I'm testing go into debug mode, clear fog. "End Turn" grays. Click on map. "End Turn" lights up. Note that the button is active, just displayed wrong. 20161021 21:30:22-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev 20161021 21:36:39< tad_carlucci> gfgtdf, About MP Scenario 2p Dark Forest (Survival) .. is this supposed to be a working scenario or is it under development? 20161021 21:38:10< gfgtdf> tad_carlucci: it durrently doesnt work becasue of issues with the gui2 mpcreate screen, to make it rowk your can wokr around the nonnpresent variable by addons a (wesnoth.get_variable("enemey_gold_factor") or 0 ) there 20161021 21:38:13< gfgtdf> currently* 20161021 21:38:29< gfgtdf> tad_carlucci: but ten you most likeley wouldnt be able t o reproduce the crash 20161021 21:38:43< gfgtdf> then* 20161021 21:38:57< tad_carlucci> OK. That explains it. 20161021 21:39:24< tad_carlucci> (1) If I clear the WML variable not found (nil value) problems, the scenario runs fine. 20161021 21:39:31< tad_carlucci> So I am ignoring those issues. 20161021 21:40:03< tad_carlucci> (2) I will track down why the nil causes a heap/stack/? overflow. It should die instead. 20161021 21:40:41< tad_carlucci> I just need to determine which variable I need to leave nil to cause the issue. 20161021 21:42:40< gfgtdf> tad_carlucci: the nil value doesnt casue teh overflow diretly, te overflow happen later (in the side turn event i think) while the nil happens in prestart event 20161021 21:43:39< tad_carlucci> The nil is the root of the problem. The question is which (there are several) and where. Working on which now. 20161021 21:43:57< mattsc> celticminstrel: how’s this: http://imgur.com/a/Tkdgj (in the chat window) and http://pastebin.com/Ti9ci7FC at stderr 20161021 21:44:16-!- Appleman1234_ is now known as Appleman1234 20161021 21:44:35< mattsc> The “start time” line is not part of it (that comes from my add-on), I just copied it in for contrast. 20161021 21:44:58< mattsc> And then you can change the “When executing …” string to whatever you think is right. 20161021 21:46:14< mattsc> So this is done by passing the string to error() and removing the wesnoth.message() line. 20161021 21:46:56< mattsc> (and as always, units are identified by their coordinates, but that’s beside the point here) 20161021 21:48:10-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20161021 21:48:30-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai] 20161021 21:48:31-!- travis-ci [~travis-ci@ec2-54-163-72-31.compute-1.amazonaws.com] has joined #wesnoth-dev 20161021 21:48:32< travis-ci> wesnoth/wesnoth#11688 (master - 15afec7 : gfgtdf): The build was fixed. 20161021 21:48:32< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/169624813 20161021 21:48:32-!- travis-ci [~travis-ci@ec2-54-163-72-31.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161021 21:49:01-!- mjs-de [~mjs-de@x4e3009d8.dyn.telefonica.de] has joined #wesnoth-dev 20161021 21:51:01-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20161021 21:58:59< tad_carlucci> Is this a known and ignored error? error audio: tried to add duplicate track 20161021 22:01:53-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 256 seconds] 20161021 22:05:04< gfgtdf> tad_carlucci: havnt hard this befor, but i usuualy play without sund when debuggon things. 20161021 22:07:20< tad_carlucci> Probably from this scenario, then. I'm still working out the crashes and trying to figure out why it dumped core. When I got it running, it dumped again on the final turn. Probably related, dunno yet. 20161021 22:11:17-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20161021 22:12:20< tad_carlucci> attempt to call a nil value (field 'child_range') .. from a line reading: for tag in wesnoth.child_range(spawn, "type") do 20161021 22:12:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161021 22:13:20-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20161021 22:14:06< celticminstrel> mattsc: Looks fine to me 20161021 22:18:22< tad_carlucci> celticminstrel, Is there a function "wesnoth.child_range"? 20161021 22:19:03< celticminstrel> tad_carlucci: It's in the helper.lua library. 20161021 22:19:14< celticminstrel> .child_range(cfg, tag_name) 20161021 22:19:27< tad_carlucci> So it should read "helper.child_range"? 20161021 22:20:26< celticminstrel> Yeah. Sometimes it's called H instead of helper. 20161021 22:22:25< tad_carlucci> That helped. Now to find the next error. This scenario may have once worked but not any more. I can't debug the engine until I debug the WML and Lua ... 20161021 22:22:31< tad_carlucci> Ah well. 20161021 22:27:24-!- Bonobo [~Bonobo@2001:44b8:254:3200:7c21:2773:dc23:40fd] has joined #wesnoth-dev 20161021 22:33:03< matthiaskrgr> can confirm that #25194 is still crashing 20161021 22:33:26-!- mjs-de [~mjs-de@x4e3009d8.dyn.telefonica.de] has quit [Remote host closed the connection] 20161021 22:35:50< tad_carlucci> matthiaskrgr, Yeah. The code is a mess. I think I'm close to getting it into shape where I can track down why the errors crashed the engine. I've got at least two crashes to check into, maybe three. 20161021 22:36:43< tad_carlucci> Right now I'm trying to figure out why fixed_spawn was never initialized. 20161021 22:36:53< matthiaskrgr> lol 20161021 22:37:09< matthiaskrgr> there is this small math test thingy in the -t test scenario 20161021 22:37:17< matthiaskrgr> it can perform division 20161021 22:37:29< matthiaskrgr> and it will crash when dividing by zero :D 20161021 22:38:11< matthiaskrgr> ( go to Open Sesame and then Math test ) 20161021 22:39:26< tad_carlucci> matthiaskrgr, If you want to get to where I am (1) set configure_gold_factor to 1 and (2) change wesnoth.child_range to helper.child_range 20161021 22:40:13< matthiaskrgr> er 20161021 22:40:18< matthiaskrgr> what file? 20161021 22:40:39< tad_carlucci> 2p_Dark_Forecast.lua 20161021 22:41:35< tad_carlucci> For some reason the prestart to initialize fixed_spawn isn't doing it. Right now I have a 'or {}' to get past that. 20161021 22:42:06< matthiaskrgr> oh hmm :) 20161021 22:42:11< matthiaskrgr> well that doesn't seem to crash anymore 20161021 22:44:42< tad_carlucci> matthiaskrgr, Crashes just fine for me if I don't set the gold factor to 1 20161021 22:48:48< matthiaskrgr> fun 20161021 22:49:14< gfgtdf> tad_carlucci: you say the [fixed_spawn] wml array isnt beeing created? 20161021 22:49:15< matthiaskrgr> (wesnoth.get_variable("enemey_gold_factor")) didn't crash here 20161021 22:49:23< matthiaskrgr> but (wesnoth.get_variable("enemey_gold_factor") + 100)/100 did 20161021 22:50:10< tad_carlucci> gfgtdf, Correct 20161021 22:50:26< gfgtdf> tad_carlucci: you used the :inspect windows fo find that out ? 20161021 22:50:29< tad_carlucci> matthiaskrgr, Makes sense. It just needs to be a number. 20161021 22:50:52< tad_carlucci> gfgtdf, Yes. And so the ref I added 'or {}' to try to run to victory. 20161021 22:55:15< gfgtdf> tad_carlucci: i just copied that content of the prestart event to wesnoth 1.12.5 and it crteteled the wml array there just fine 20161021 22:55:53< tad_carlucci> What is "T.type"??? 20161021 22:56:08-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20161021 22:56:23-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind] 20161021 22:57:27< gfgtdf> its fucntion T.type { ... } retunn {{ "type"}, { .. }} which is now wml dpocuments are encoded in lua 20161021 22:57:37< gfgtdf> how* 20161021 22:58:38< tad_carlucci> Where is it defined? I do remember that now. Maybe there's a require missing or errored. 20161021 22:58:53< tad_carlucci> found it 20161021 23:01:12-!- Netsplit *.net <-> *.split quits: heirecka, gfgtdf, pydsigner, crimson_penguin, celticminstrel, Yaiyan, aidanhs, clavi, Appleman1234, iwaim, (+1 more, use /NETSPLIT to show all of them) 20161021 23:01:16-!- Netsplit *.net <-> *.split quits: higgins, skeletenchi, mattsc, Bonobo, ToBeCloud, new_one 20161021 23:01:37-!- Netsplit *.net <-> *.split quits: Soliton, Porusaka, wedge009, vincent_c, Jetrel, _laco, EliDupree, elias, knotwork, Ivanovic, (+20 more, use /NETSPLIT to show all of them) 20161021 23:01:49-!- Netsplit over, joins: APic 20161021 23:02:19-!- Netsplit over, joins: yaiyan 20161021 23:05:12-!- esr [~esr@wesnoth/developer/esr] has quit [Ping timeout: 260 seconds] 20161021 23:05:22-!- clavi [~clavi@163-172-10-77.rev.poneytelecom.eu] has joined #wesnoth-dev 20161021 23:06:40-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev 20161021 23:06:40-!- _laco [~laco@static.183.80.201.138.clients.your-server.de] has joined #wesnoth-dev 20161021 23:06:59-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20161021 23:06:59-!- Bonobo [~Bonobo@2001:44b8:254:3200:7c21:2773:dc23:40fd] has joined #wesnoth-dev 20161021 23:06:59-!- higgins [~higgins@68.ip-149-56-14.net] has joined #wesnoth-dev 20161021 23:06:59-!- new_one [~new_one@2604:a880:1:20::22e:d001] has joined #wesnoth-dev 20161021 23:07:21-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev 20161021 23:07:21-!- shadowm [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev 20161021 23:07:21-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20161021 23:07:21-!- kidneb_ [~kidneb@178.79.173.107] has joined #wesnoth-dev 20161021 23:07:21-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev 20161021 23:07:32-!- skeletenchi [enchilado@gateway/shell/blinkenshell.org/session] has joined #wesnoth-dev 20161021 23:07:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 23:07:32-!- Porusaka [~Polsaker@donger/wielder/Polsaker] has joined #wesnoth-dev 20161021 23:07:32-!- knotwork [~markm@unaffiliated/knotwork] has joined #wesnoth-dev 20161021 23:07:46-!- aidanhs [~aidanhs@81.4.110.234] has joined #wesnoth-dev 20161021 23:07:46-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161021 23:07:59-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161021 23:07:59-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev 20161021 23:07:59-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20161021 23:07:59-!- oldlaptop [~quassel@162.247.150.37] has joined #wesnoth-dev 20161021 23:08:18-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has joined #wesnoth-dev 20161021 23:08:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161021 23:08:19-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev 20161021 23:08:19-!- matthiaskrgr [matthiaskr@gateway/shell/panicbnc/x-rfdkonskvcclgsqp] has joined #wesnoth-dev 20161021 23:08:19-!- midzer [~quassel@p57B45F9C.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161021 23:08:19-!- Soliton [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev 20161021 23:08:19-!- Lohengramm [sid1929@gateway/web/irccloud.com/x-dadfvjpayltsiixw] has joined #wesnoth-dev 20161021 23:08:19-!- elias [~allefant@allegro/developer/allefant] has joined #wesnoth-dev 20161021 23:08:26-!- iwaim [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev 20161021 23:08:26-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20161021 23:08:26-!- EliDupree [~quassel@2604:a880:400:d0::9bb:2001] has joined #wesnoth-dev 20161021 23:08:26-!- Jetrel [~Jetrel@2001:558:6014:1e:2422:435:dd84:bbf3] has joined #wesnoth-dev 20161021 23:08:26-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20161021 23:08:29-!- aeth [~Michael@c-69-138-234-99.hsd1.md.comcast.net] has joined #wesnoth-dev 20161021 23:11:05-!- Lohengramm [sid1929@gateway/web/irccloud.com/x-dadfvjpayltsiixw] has quit [Ping timeout: 250 seconds] 20161021 23:13:00-!- gfgtdf [~chatzilla@x4e368475.dyn.telefonica.de] has joined #wesnoth-dev 20161021 23:13:00-!- irker752 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161021 23:13:00-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has joined #wesnoth-dev 20161021 23:13:00-!- Greywhind [~Greywhind@c-71-232-25-123.hsd1.ma.comcast.net] has joined #wesnoth-dev 20161021 23:13:00-!- minbonbon [~min@meta23.net] has joined #wesnoth-dev 20161021 23:13:45-!- aeth is now known as Guest41419 20161021 23:14:09-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has joined #wesnoth-dev 20161021 23:14:09-!- Appleman1234 [~Appleman1@KD106181173238.au-net.ne.jp] has joined #wesnoth-dev 20161021 23:14:12-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev 20161021 23:14:15-!- Guest41419 [~Michael@c-69-138-234-99.hsd1.md.comcast.net] has quit [Quit: Reconnecting] 20161021 23:14:31-!- aeth_ [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev 20161021 23:14:48-!- skeletenchi [enchilado@gateway/shell/blinkenshell.org/session] has quit [Changing host] 20161021 23:14:48-!- skeletenchi [enchilado@gateway/shell/blinkenshell.org/x-czbxifzjlfojptjq] has joined #wesnoth-dev 20161021 23:15:09< tad_carlucci> gfgtdf, OK. It's creating the fixed_spawn table. Don't know why it wasn't there before. 20161021 23:15:41-!- aeth_ is now known as aeth 20161021 23:27:10-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 23:29:54-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20161021 23:30:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds] 20161021 23:31:43-!- Lohengramm [sid1929@gateway/web/irccloud.com/x-ywasjupynbhqrwjx] has joined #wesnoth-dev 20161021 23:33:40-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161021 23:37:16< tad_carlucci> Bam. There's a 5.2.3 -> 5.3.3 change 20161021 23:38:09< gfgtdf> tad_carlucci: ? 20161021 23:39:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161021 23:40:13-!- ancestral [~ancestral@63.236.20.2] has joined #wesnoth-dev 20161021 23:41:08-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20161021 23:45:54< tad_carlucci> Oh. the places it builds a variable name [ .. index ... ] well, the index is coming as "2.0" instead of "2" 20161021 23:46:05< tad_carlucci> There's a compat option about that, I think. I'll check. 20161021 23:46:16< tad_carlucci> It's part of the integer vs float change 20161021 23:47:28< tad_carlucci> quoting: The conversion of a float to a string now adds a .0 suffix to the result if it looks like an integer. (For instance, the float 2.0 will be printed as 2.0, not as 2.) You should always use an explicit format when you need a specific format for numbers. 20161021 23:48:27< tad_carlucci> So if there's no compat option there's a fix. Odd thing is the explicit format is used elsewhere I've seen. So it's not new. 20161021 23:53:57< tad_carlucci> Compiling to test the compat option, now. 20161021 23:55:30< gfgtdf> tad_carlucci: that sonds like it's more or less undefined whether a tostring() will return 2.0 or just 2 here. 20161021 23:56:34< tad_carlucci> It's unclearly worked but they're trying to say, yes, it adds .0 20161021 23:58:01-!- ancestral [~ancestral@63.236.20.2] has quit [Quit: i go nstuf kthxbai] 20161021 23:59:03< celticminstrel> I guess that's a place where it's safe to use string.format though. --- Log closed Sat Oct 22 00:00:07 2016