--- Log opened Tue Sep 13 00:00:56 2016
20160913 00:05:27-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160913 00:06:31< tad_> Wesnoth is so unnecessarily hard to mod. I'd offer to fix it but the hard-coded pathnames are in so many places. I give up. The 'best' way I can see to test something with 1.12.6 is to backup the campaign, mess with it, and restore the backup.
20160913 00:07:17< celticminstrel> What sort of hard-coded pathnames are we talking about.
20160913 00:07:39< tad_> {data/campaign/ ...
20160913 00:08:01< tad_> I fix one and there's sixteen more which prevent my change from working ..
20160913 00:08:22< celticminstrel> Ah.
20160913 00:08:37< tad_> So it's 'sudo su' and make a backup time. I'm tired of fighting with it.
20160913 00:08:38< celticminstrel> Things in data/ could be made to use more relative paths, I guess.
20160913 00:09:38< vultraz> data/campaigns is done since that's a binary path-independent path
20160913 00:09:51< tad_> If it all was relative to the file with [campaign] maybe. But that's a HUGE change buried in macros.
20160913 00:10:36< tad_> If you want to mod, you have to work in the 'live' data/campaigns or spend a day finding all the places it's hidden and change it to someplace else ..
20160913 00:11:42< tad_> Probably a command line but when I tried THAT it looks like the package maintainer hard-coded THAT because it's such a mess and he didn't want to fix it so he whacked it in the c++
20160913 00:13:01< tad_> I'm just frustrated because I wanted to just make a 'quick' change. tar/change/untar will do it so that's what I'll do
20160913 00:13:43-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160913 00:15:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160913 00:17:52-!- Bonobo [~Bonobo@2001:44b8:254:3200:103:83e6:6e16:7741] has quit [Ping timeout: 255 seconds]
20160913 00:18:39-!- Bonobo [~Bonobo@2001:44b8:254:3200:34a5:1ed7:d519:e959] has joined #wesnoth-dev
20160913 00:18:55< tad_> Sometimes ya gotta do what ya gotta do. Otherwise we'd not have 'sudo' ...
20160913 00:29:54< shadowm> ... Okay, so if you want to test a change to a mainline campaign you presumably have access to the original files somehow, either because you have the tarball/installer around or are using Git because you want to contribute to mainline
20160913 00:30:30< shadowm> So what is the problem again?
20160913 00:33:03< tad_> shadowm: Me? I have master checked out and that's not the issue except I can't checkout 1.12.6 and 'make all' to get a running 1.12.6. So I have to use the Arch package for 1.12.6 and it's root-owned in /usr/share and I don't want to blow it away. So you can't copy LoW to addons .. won't work because it's hard code paths .. so I gave up and backed up /usr/share/wesnoth and will restore it when I'm done.
20160913 00:33:34< shadowm> You're approaching things from the wrong angle then.
20160913 00:33:54< shadowm> Let's start from square zero. Why can't you build the 1.12.6 tag or the 1.12 branch?
20160913 00:34:47< shadowm> (Also, since we don't use plain Makefiles there's really no way `make all` will do anything on a fresh source tree.)
20160913 00:34:48< tad_> shadowm: If I recall, it's that Boost didn't provide some function which 1.12.6 needed. It was a mess and I don't want to roll back all my support libraries just to compile.
20160913 00:34:57< shadowm> Which Boost version is this?
20160913 00:35:25-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160913 00:35:26< tad_> 1.61.0
20160913 00:35:40< shadowm> Let me make one thing clear: 1.12 has not reached EOL yet, therefore if 1.12 can't be built on a supported platform for whatever reason, that's a bug you ought to report.
20160913 00:36:06< shadowm> The first thing we need is see the build log.
20160913 00:37:02< tad_> Well, it's been a couple days and I'm off on another issue.
20160913 00:37:09< shadowm> I'd also advise using the 1.12 branch rather than a released tag if your intention is to get a patch submitted for mainline.
20160913 00:37:19< shadowm> *accepted in
20160913 00:37:44< shadowm> I'm building 1.12 on Debian sid right now, which has Boost 1.61 as the default.
20160913 00:37:47< tad_> My intention was to bisect from the 1.12.6 tag to current HEAD to find where an issue appeared.
20160913 00:38:38< shadowm> That will presumably take an absurd amount of time.
20160913 00:38:41< tad_> But somewhere before 1.13.3 it started getting symbol-not-found (iirc) for some Boost internal
20160913 00:38:55< shadowm> 21:38:38 shadowm@nanacore git:1.12 ~/src/wesnoth-1.12 % git log --format=oneline 1.12.6..master | wc -l
20160913 00:38:59< shadowm> 9969
20160913 00:39:06-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160913 00:39:31< shadowm> I assume that by "current HEAD" you meant master rather than the 1.12 HEAD which is younger than 1.12.6.
20160913 00:39:41< tad_> shadowm: Yep. It said bisect would take 100 or so steps but that's fine by me. 
20160913 00:39:56< shadowm> Because that bisect is really backwards.
20160913 00:40:17< shadowm> The 1.12 branch (and all its children tags) diverged from master after version 1.11.11.
20160913 00:40:55< tad_> shadowm: Anyway, when it failed to compile and I could not step a few hundred commits to get a clean compile (like it was a bad commit) I gave up and we worked around the issue another way.
20160913 00:41:36< shadowm> Okay, so 1.12 builds with Boost 1.61 for me.
20160913 00:42:19< shadowm> Speaking as release manager of the 1.12 series, I really want to know what is the exact issue you get when building 1.12 (not 1.12.6) with Boost 1.61.
20160913 00:42:57< tad_> And it builds for the package maintainer. I'm good with that. I really only care that 1.13.5+dev builds and, every now and then, that I can bisect back a few weeks to find where a bug appeared.
20160913 00:43:03< shadowm> (Worth noting that src/ and the CMake and SCons recipe files are almost unchanged from 1.12 to 1.12.6.)
20160913 00:43:14< shadowm> *from 1.12.6 to the 1.12 HEAD
20160913 00:43:47< shadowm> (Important distinction there. Each branch has its own HEAD.)
20160913 00:44:07< celmin> shadowm: When will you get to reviewing the campaignd PR?
20160913 00:44:16< shadowm> celmin: In an hour or so.
20160913 00:44:45< tad_> I did a bisect and it went back to 1.13.3 or thereabouts and failed. I stepped a few hundred commits and it still failed. So I gave up and we worked the issue without caring about where it appeared.
20160913 00:45:11< shadowm> I can positively say I feel more encouraged to do that review now that master actually builds without having to mess around with stuff.
20160913 00:45:35< shadowm> tad_: So you've got me confused here. Were you trying to bisect the build failure, or whatever bug you were chasing in a mainline campaign?
20160913 00:47:13< tad_> shadowm: I was starting from 1.13.5+dev current master/HEAD at that time and we determined 1.12.6 did not show the error, 1.13.3 did and when I started a bisect it errorred and I stepped the bisect a few hundred commits and it still errored so I gave up.
20160913 00:47:45< tad_> shadowm: That's all in the past. I could probably re-create it. But no point.
20160913 00:48:45< shadowm> The build failure then.
20160913 00:49:07< tad_> shadowm: The problem today is I need to check how some things worked on 1.12.6 wrt map, terrain mask, and leader placement. And I could not make a copy because the binary ignored my command-line switch. So I went su and made a backup before I blew away the originals.
20160913 00:49:22< shadowm> Okay, so here's a tip for the future: *never* perform bisect or merge or diff operations across master and a maintenance branch.
20160913 00:50:11< shadowm> You will never get the intended results due to history diverging completely past the initial branching point.
20160913 00:51:17< shadowm> It's like 1.12 is a gorilla and master is a chimpanzee. They may look similar to the casual observer but you can't really breed them together.
20160913 00:52:07< tad_> So saying 'It works on 1.12.6' has no meaning because what was done to 1.12.6 may not appear on the current master?
20160913 00:52:33< vultraz> celmin: what would this macro even do? #define SDL_EVENTMASK(EVENT) EVENT, EVENT
20160913 00:52:42< shadowm> tad_: Depends greatly on the particular context.
20160913 00:52:59< tad_> ok
20160913 00:53:45< tad_> Does that hold for all tags? Like 1.13.3 vs current master/HEAD? I should work with relative commits from master/HEAD and ignore tags?
20160913 00:53:50< shadowm> For example, 1.12.x (1.12) and 1.13.x (master) both carry a security patch that was not in 1.12.w (old 1.12) or 1.13.w (old master).
20160913 00:54:28< shadowm> But the patch has completely different hashes and the exact contents differ slightly because the codebase in 1.12 and master was already different enough.
20160913 00:56:13< shadowm> So you can say, as a human, that the patch is in both branches, but Git won't agree with you.
20160913 00:56:15< tad_> shadowm: In general, the issue when I'm looking at the C++ is how to fix it on the master/HEAD and I only care to find the commit where it broke because it helps me learn what does what, where.
20160913 00:56:22< irker961> wesnoth: Charles Dang wesnoth:surface_cleanup 7d916c295e03 / src/sdl/utils.cpp: Removed old Pandora compatibility code https://github.com/wesnoth/wesnoth/commit/7d916c295e038576439ea3542a089b8a36ea2a10
20160913 00:56:25< irker961> wesnoth: Charles Dang wesnoth:surface_cleanup c4497595bae6 / src/ (5 files in 2 dirs): Refactored out create_optimized_surface https://github.com/wesnoth/wesnoth/commit/c4497595bae651964b2677d88764224ad4043490
20160913 00:57:43< shadowm> So more generally, you can use tags that are *ancestors* of the same commit/branch as bisect points. For example, 1.13.0 is an ancestor of 1.13.5, and also current master.
20160913 00:58:36< shadowm> But 1.13.0 is not an ancestor of 1.12.6 and 1.12.0 (or 1.11.12 if you want to go further back) is not an ancestor of 1.13.0.
20160913 00:58:46< tad_> shadowm: The issue, today, though is how to change LoW to test how 1.12.6 worked without regard to the current master/HEAD. I have a PR up and the question was how it used to work. But the test case (LoW) didn't use the feature (properly) and so I need to change 1.12.6 LoW. But, to do that, I either need to backup the original or spend hours finding all the hard-coded paths and fixing them so I can copy it into add-ons.
20160913 00:59:17< shadowm> However, 1.11.11 is an ancestor of 1.13.0 *and* 1.12.0 because 1.11.11 (approximately) was the last common ancestor of both the master and 1.12 branches.
20160913 00:59:56< tad_> shadowm: However, you got me thinking and, maybe, when I have some time to kill, I'll roll back to 1.13.3 (which I think is where I hit the error) and we can work through what I did wrong trying to build a working 1.13.3 from a checkout based on the master/HEAD
20160913 00:59:58< shadowm> So if you want to check whether an issue in master affects X.Y maintenance branch (or its descendants), the easiest and safest thing to do is to check them out separately.
20160913 01:01:49< shadowm> Also, worth noting that to my knowledge the only issue that's ever made 1.12 unbuildable with Boost 1.60 or later only pertained to the unit test target.
20160913 01:02:11< shadowm> It was fixed after 1.12.5 (i.e. 1.12.6 carries the fix).
20160913 01:03:10< tad_> shadowm: OK. Question: I have a local repo for current master/HEAD and I deleted all those old branches so when I ask it has ONLY my personal branches and master/HEAD .. when I asked for 1.12.6 tag it gave me one? Does that mean the branches are still there and I can't see them?
20160913 01:03:55< shadowm> You deleted your local branches but the remote tracking branches (and the remote tags) should still be there unless you go out of your way to delete them and keep them from being re-fetched, yes.
20160913 01:04:44< tad_> I deleted them from my 'origin' (Github personal fork). Of course, I can't change what's on 'upstream' (wesnoth/wesnoth).
20160913 01:05:25< tad_> Maybe git saw I didn't have it, and origin didn't, so it fell back to upstream?
20160913 01:05:44< shadowm> I'm not sure how Git resolves names when you have more than one remote, so it probably did that, yes.
20160913 01:06:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 01:06:27< tad_> OK. Another thing I find interesting. Easy enough to check, unplug the virtual ethernet and try it ..
20160913 01:06:28< shadowm> It also depends on how you performed said deletion.
20160913 01:07:10< shadowm> For example, you have a clone of your fork and you deleted objects from it but didn't push the deletion to its origin.
20160913 01:07:19 * tad_ shrugs.  locally: git branch -D // on github click the trashcan
20160913 01:07:32< shadowm> Or you have two clones of your fork and you deleted objects from one, pushed the deletion to its origin, but didn't re-do the deletion on the other fork.
20160913 01:08:24< shadowm> As far as I remember Git doesn't really propagate deletions to downstream repositories on pull because it doesn't keep track of who created what.
20160913 01:08:50< shadowm> i.e. the downstream repository might have objects that the upstream doesn't because they were created or recreated or restored downstream.
20160913 01:10:09< shadowm> More specifically, the exact syntax to push a deletion upstream is a bit funky and it's not exactly easy to forget that you did it.
20160913 01:10:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160913 01:11:45< shadowm> `git push <remote> :<object> [:<object2> [...]]` or `git push --delete <remote> <object> [<object2> [...]]`
20160913 01:13:52< tad_> I looked at that, decided it was too much and simply went to the web page and hand deleted all those old branches. Most are long dead and no longer maintained and, frankly, all I care about is what got us to the current master/HEAD. If a patch for 1.12.6 is needed for 1.12.7 but not for master/HEAD I probably won't care about it other than that the Arch maintainer picks it up and yaourt (like pacman) updates when it's ready.
20160913 01:14:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160913 01:15:31< shadowm> Usually the easiest way for downstream maintainers to take patches is to have them approved and merged upstream first.
20160913 01:16:15< shadowm> It's also less work for them.
20160913 01:17:02< shadowm> So yes, if you deleted branches from your fork using the GitHub web interface, I don't think they'll be deleted from your clone  on your disk drive on the next pull.
20160913 01:18:29< shadowm> You can replicate the deletions yourself and save like 2% of the repository's disk usage if you want, but the fact remains that those objects still exist in one of the remotes your clone uses and therefore there will always be at least one remote-tracking version for each of them.
20160913 01:18:30< tad_> They we're and I don't pull. I deleted using -D and I do fetch and rebase on my master. Dunno why, probably read someplace and it works so I don't look
20160913 01:19:31< shadowm> Next fetch then.
20160913 01:19:35< tad_> My clone on my hard drive only remotes to my personal github fork ('origin') I have a non-followed 'upstream' set to pull from wesnoth/wesnoth but it only works when I fetch specifically.
20160913 01:19:54< shadowm> pull is essentially a fetch followed by a merge.
20160913 01:20:23< shadowm> (Or rebase, if using --rebase or the appropriate config option.)
20160913 01:21:51< shadowm> Yeah, well, you *have* to fetch from wesnoth/wesnoth at some point (unless GitHub finally implemented a more 2010s way to synchronize forks with upstream), so the point still stands.
20160913 01:22:03< tad_> Every AM when I get up, I do the following "git checkout master" "git fetch upstream" "git rebase upstream/master" "make" and read some news, check forums, and redit, waiting for 'make' to finish since it usually takes a while
20160913 01:22:51< shadowm> Of course you could do a selective fetch and only fetch objects you're interested in, but.
20160913 01:23:35< tad_> Well, my interest is that my local master track whatever celmin and vultraz have been up to while I was asleep :P
20160913 01:24:14< vultraz> random
20160913 01:24:16< vultraz> scoped_resource& operator=(const scoped_resource&);
20160913 01:24:18< shadowm> So yeah, the bottomline is that objects you don't use don't really hurt.
20160913 01:24:22< vultraz> isn't this supposed to have = delete
20160913 01:24:30< vultraz> '= delete'
20160913 01:24:33< vultraz> *
20160913 01:24:44< shadowm> They just consume an amount of extra disk space that's a function of their relative uniqueness.
20160913 01:25:16< shadowm> So e.g. all tags together take a negligible amount of disk space as long as their ancestor branches exist.
20160913 01:26:54< shadowm> And a local branch takes up at least as much space as the trailing bit where it differs from its corresponding remote-tracking branch (if it exists).
20160913 01:27:26< shadowm> Of course this is all just a rough approximation of how Git stores its data. In reality it's all a bit more complex and compression is involved.
20160913 01:28:11< tad_> When I check, I have 'master' and my 9 personal branchs. Both locally and on github. If fetch us pulling down a new branch from wesnoth/wesnoth I don't see it.
20160913 01:30:14< shadowm> vultraz: Yes.
20160913 01:30:45< shadowm> You're lookiong at a type that predates C++11 by at least 5 years.
20160913 01:31:34< shadowm> The unimplemented private member idiom was used in C++98/03 to achieve a similar effect as deleted members, with considerably less clear compiler diagnostics.
20160913 01:32:35-!- travis-ci [~travis-ci@ec2-54-205-67-46.compute-1.amazonaws.com] has joined #wesnoth-dev
20160913 01:32:36< travis-ci> wesnoth/wesnoth#10889 (surface_cleanup - c449759 : Charles Dang): The build was fixed.
20160913 01:32:36< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159467875
20160913 01:32:36-!- travis-ci [~travis-ci@ec2-54-205-67-46.compute-1.amazonaws.com] has left #wesnoth-dev []
20160913 01:32:56< shadowm> For that matter, you are also expected to delete the copy constructor for that type.
20160913 01:35:20< vultraz> I wonder if this class could be replaced with std::unique_ptr.
20160913 01:36:51< vultraz> as with this custom scoped_ptr implementation...
20160913 01:37:50< vultraz> celmin: thoughts?
20160913 01:39:52< vultraz> pretty sure it can handle scoped_array too
20160913 01:41:17< vultraz> ah, but would unique_ptr doesn't work with SDL_Surface..
20160913 01:42:01< shadowm> unique_ptr doesn't have an option to specify a release policy, so no.
20160913 01:42:30< vultraz> It does
20160913 01:43:09< shadowm> Huh, indeed it does.
20160913 01:44:29< shadowm> SDL_Surface in 1.2 was special in that it was reference counted.
20160913 01:44:44< shadowm> shared_ptr would approximate that functionality better.
20160913 01:45:44< shadowm> Hoo boy.
20160913 01:46:04< shadowm> http://www.boost.org/doc/libs/ , which is linked from the Boost front page itself, is now 404ing.
20160913 01:47:44< shadowm> Okay, so my misconception WRT unique_ptr stems from Boost's scoped_ptr not having said feature.
20160913 01:53:34< celmin> [Sep 12@8:52:33pm] vultraz: celmin: what would this macro even do? #define SDL_EVENTMASK(EVENT) EVENT, EVENT
20160913 01:53:35< celmin> Well, I guess it would evaluate the expression EVENT twice? Seems pretty odd though, I'd expect it to be defined as something like 1 << EVENT.
20160913 01:54:04< celmin> unique_ptr does have an option to specify a release policy but seems to fail on incomplete types.
20160913 01:55:12< vultraz> well, I'm going to try using shared_ptr here
20160913 01:55:50< vultraz> (in surface, that is)
20160913 01:55:59< vultraz> I think.. the assign function would be unnecessary, then?
20160913 01:56:31< tad_> OK. Vote time! Should 1.13.5+ [terrain_mask] emulate the errors in 1.12.6 so we don't break content? If so, should I then add another flag ('unfuck_mask_implementation=yes|no' default no) so 1.13 and later does it wrong by default?
20160913 01:57:42< vultraz> celmin: I think if I should just be able to do surface a = surf, right? no need for a.assign(surf)
20160913 01:57:53< vultraz> = called assign anyway..
20160913 01:57:59< vultraz> which confuses me :/
20160913 01:58:02< tad_> I've been testing how 1.12.6 does [terrain_mask] .. works fine for terrain, just what  you'd expect. But it's hosed when it comes to leader positions. They work but boy-howdy it's a mess
20160913 01:58:30< celmin> I dunno.
20160913 01:58:32< celmin> Maybe.
20160913 01:58:37< celmin> ^ vultraz 
20160913 01:58:44< vultraz> I'll remove it and test
20160913 01:58:44 * tad_ nods.
20160913 01:58:50< celmin> tad_: Which errors?
20160913 01:58:50< vultraz> damn this file for causing huge rebuilds..
20160913 01:58:57< shadowm> tad_: If the default isn't going to be backwards-compatible then wouldn't it make more sense to document clearly how to detect and fix the compatibility issue?
20160913 01:59:20< shadowm> Otherwise you still have to do the latter to decide where to insert the compatibility switch.
20160913 01:59:25< tad_> shadowm: Describing them is going to be a paint. I might need a PDF with images ...
20160913 02:00:07< shadowm> Just my observations, anyway. I don't care/can't care about master atm.
20160913 02:00:19< celmin> Except the campaignd, right?
20160913 02:00:28< celmin> Or does that count as not master?
20160913 02:00:32< shadowm> https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20160912_225519.png
20160913 02:00:42< tad_> shadowm: Which is fine. Someone needs to keep up the current-stable stuff.
20160913 02:00:47< shadowm> I'm on it, only have to rebuild a considerably older source.
20160913 02:01:32< shadowm> Because there are too many large conflicts for me to resolve.
20160913 02:01:58< shadowm> Oh hey what do you know, now I hit an error that was fixed ages ago.
20160913 02:02:14< shadowm> Maybe I'll switch to GCC 5 then.
20160913 02:03:25< tad_> celmin: consider a 30x30 map and a 10x10 mask, offset by (5,5) .. Put "Gs" at (1,1) on the mask. It appears at (6,6) on the map, as expected. Change it to "1 Gs" so leader 1 appears there. The grass is still at (6,6) but the leader appears at (1,1). Change the offset to (10,10) and the grass moves to (11,11) as expected but the leader still appears at (1,1).
20160913 02:04:41< tad_> celmin: So it's impossible to test what happens if the original map had the leader at (2,2) and the offset mask also has him at (11,11) since it errors him to (1,1) and clears the (2,2) because that's inside the mask
20160913 02:05:33< tad_> Not that clearing the (2,2) matters because the only places the underlying map can put the leader and create a duplicate are on the right and bottom edges and I can't find a way to test 'map overrides mask' because of than.
20160913 02:10:16< celmin> Kinda sounds like the old behaviour isn't worth preserving, but I'm not 100% sure.
20160913 02:10:18 * shadowm takes a deep breath.
20160913 02:10:19< tad_> The solution is simple: add the +offset which was forgotten. But that breaks backward compatibility. So do we care? It wasn't very logical back then so I'm betting NOBODY used it.
20160913 02:11:00< vultraz> just do it.
20160913 02:11:53< shadowm> Switching back to GCC 6.
20160913 02:12:02< tad_> That's my leaning. We'll do it and if some UMC author complaints, shadowm can pass it to me and I'll do a special switch if he *really* can't update his campaign.
20160913 02:12:17< shadowm> Mine?
20160913 02:12:26< tad_> No.
20160913 02:12:30< shadowm> They are already broken in 1.13.x and I've no interest in--
20160913 02:12:47< shadowm> Oh, the hypothetical UMC author, I see.
20160913 02:13:14< shadowm> No, just mention this clearly in the release notes and make sure that zookeeper or whoever adds it to the sticky in WML Workshop (?).
20160913 02:13:15< tad_> Yeah. I can't see how one would design based upon the mess, but I s'pose it'
20160913 02:13:21< shadowm> *changelog and release notes
20160913 02:13:45< shadowm> You'd be surprised how many people rely on broken behavior across the entire tech industry.
20160913 02:13:48< tad_> s it's possible and even possible to be so dependent that it's easier to add the switch than fix thecampaiogn
20160913 02:14:13< tad_> Hey, I do Javascript .. I know all about broken behavior ..
20160913 02:14:58< shadowm> Ah, the joys of working with a stale branch.
20160913 02:15:23-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160913 02:15:27< shadowm> Switched to GCC 6 and backported a relevant patch since apparently Boost was built in such a way it breaks horribly with GCC 5 now.
20160913 02:15:32< tad_> OK. I'm going to take what I learned, fix the PR and see if I can clearly explain what to watch out for so zookeeper can guide the UMC authors into the light.
20160913 02:15:44< shadowm> (Which probably means I can just dispose of GCC 5 entirely.)
20160913 02:16:14< shadowm> Or... not.
20160913 02:16:26< shadowm> Seems like 90% of my system needs GCC 5.
20160913 02:17:01< tad_> gcc 5, I'd say "probably" but I've seen a lot of breakage happen for stuff which works on gcc 4 and breaks on 5 and 6
20160913 02:17:31< shadowm> It's because of the ABI breakage nonsense that happened as a side-effect of embracing C++11.
20160913 02:18:34< shadowm> I'm not entirely sure why GCC 6 seems to introduce more ABI shenanigans but whatever, I have enough space for a dozen GCCs if needed.
20160913 02:20:55< shadowm> Since when is there a "the remote version of this add-on is greater or equal to the version being uploaded" warning?
20160913 02:21:26< tad_> About the same time the "has not _info.cfg" message appeared ???
20160913 02:21:54< shadowm> Not really.
20160913 02:23:02< vultraz> shadowm: I added it in August 2015
20160913 02:23:12< vultraz> ad127d662f6431520
20160913 02:23:31< shadowm> Eh whatever.
20160913 02:24:30< tad_> Well, I need to restore my 1.12.6 back to pristine condition and do a lot more testing and correcting for that PR so [terrain_mask] honors the special positions properly and I can clean up that part of LoW and be done with that console message which started me down this rabbit hole.
20160913 02:24:52< vultraz> It's to guard against accidentally forgetting to bump a version number :P
20160913 02:25:26< tad_> vultraz: sounds like a good and valuable check. But is there a way to force past it if you really need to?
20160913 02:25:32< vultraz> Yes
20160913 02:25:44< vultraz> It's a "Do you really wish to continue" warning
20160913 02:25:50< tad_> noce
20160913 02:25:52< tad_> nice even
20160913 02:26:12< shadowm> The very definition of a warning implies you can choose to ignore it.
20160913 02:26:44< shadowm> I just got confused because I forgot how this thing works.
20160913 02:27:06< tad_> Well, usually. But I've been hitting warnings which people have been ignoring in mainline campaigns which .. sure they ran .. but not the way they should have.
20160913 02:27:35< shadowm> Can, not should. :p
20160913 02:28:18< tad_> Might be interesting to add -Werror as a command line option and see where the smoke appears ...
20160913 02:28:32< tad_> To wesnoth and wesnothd, that is.
20160913 02:28:38< shadowm> I know one add-on that wouldn't work at all.
20160913 02:28:45< vultraz> hehehehe
20160913 02:28:53< shadowm> Hehehe, indeed.
20160913 02:38:24-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160913 02:39:11< shadowm> First thing I find while trying to locate logs pertaining to this PR is that incident where I tried to back up the entire x86_64 address space to a 2 TiB disk drive.
20160913 02:53:07-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Read error: Connection reset by peer]
20160913 02:58:36< vultraz> :(
20160913 02:58:42< vultraz> i broke wesnoth
20160913 03:00:38< vultraz> not even sure why...
20160913 03:01:56< vultraz> segfault in sdl somewhere :/
20160913 03:09:36< vultraz> hm.
20160913 03:11:02< shadowm> I can see config reload issues with the campaignd port still.
20160913 03:12:31< shadowm> Wait, uh.
20160913 03:12:58< shadowm> My mistake (although I've no idea what I did wrong exactly).
20160913 03:14:15< vultraz> celmin: have i done something obviously wrong here http://pastebin.com/K51y9nrD
20160913 03:16:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 03:17:32< vultraz> I'm pretty sure I do need operator= for a surface pointer, but..
20160913 03:20:41< shadowm> Does SDL_Surface still have a reference counter in it?
20160913 03:20:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20160913 03:20:50< shadowm> If so, what you are doing is a really bad idea.
20160913 03:21:28< vultraz> hmmm it looks like it does.
20160913 03:21:44< shadowm> shared_ptr keeps a separate refcount, so the container object's refcount is obviously going to be out of sync.
20160913 03:22:21< shadowm> I'm not sure if SDL uses the refcount internally, but if it does it may decide to destroy the surface at unexpected times.
20160913 03:22:31< shadowm> *contained
20160913 03:23:22< shadowm> "Read-mostly", says the header. Hm.
20160913 03:24:10< vultraz> could one use a unique_ptr in place of utils::scoped_resource and keep the manual bumping of SDL_Surface's refcount?
20160913 03:25:09< shadowm> It _seems_ like to SDL the refcount is kind of irrelevant as long as you don't go around calling SDL_FreeSurface before your external refcount reaches zero.
20160913 03:25:43< celmin> surface& operator=(surface o)
20160913 03:26:18< shadowm> vultraz: No, you can't use unique_ptr without changing considerably how these objects get used.
20160913 03:26:26< celmin> I have no idea about this thing about SDL_Surface internal refcounts.
20160913 03:26:46< shadowm> At least with SDL 1.2 we used to pass surfaces around and copy them and delete them relying on their sharedness attribute.
20160913 03:26:59< shadowm> unique_ptr is obviously not intended to be shared (hence it's not copyable).
20160913 03:28:03< shadowm> I'm going to do that thing you really don't like and ask you what you're expecting to get out of altering this class.
20160913 03:28:11< celmin> ^
20160913 03:28:29< celmin> i don't really get what you're doing or why.
20160913 03:28:47< shadowm> I did say shared_ptr could be used to _approximate_ this functionality, but I did not recommend doing so.
20160913 03:29:48< shadowm> To me it seems like you intend to apply some kind of dogmatic coding style rule to something that does not benefit from it in any practical way.
20160913 03:29:50< celmin> (If we wanted to use shared_ptr for surfaces, then "surface" would probably be a function instead of a class.)
20160913 03:31:38< celmin> vultraz: BTW, make_shared is for when you need to create a new object, not for when you already have a pointer to one.
20160913 03:32:41< celmin> And I think it requires an explicit template argument as well.
20160913 03:37:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 03:38:07-!- Bonobo [~Bonobo@2001:44b8:254:3200:34a5:1ed7:d519:e959] has quit [Ping timeout: 255 seconds]
20160913 03:40:03< shadowm> AFAICT if we used shared_ptr, the the memory layout of our `surface` type would change from { SDL_Surface* -> { [...], nativeword } } to { SDL_Surface* -> { [...], nativeword }, unspecified_type* -> { SDL_Surface, unspecified_type*, unspecified_type*, unspecified_type, unspecified_type }
20160913 03:41:31< shadowm> And we'd also gain some thread safety for refcount changes that I don't think we can benefit from?
20160913 03:42:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160913 03:42:41< shadowm> (Note: it seems the entire layout of shared_ptr is unspecified, so that's a very theoretical example.)
20160913 03:43:59< shadowm> (Yes, we don't benefit from thread-safe refcount: https://wiki.libsdl.org/FAQDevelopment#Can_I_call_SDL_video_functions_from_multiple_threads.3F )
20160913 03:45:30< vultraz> I kinda ended up on a tangent..
20160913 03:46:11< vultraz> It started because I wanted to add a renderer getter method to surface
20160913 03:46:19< vultraz> Then I noticed the use of this scoped_resource thing
20160913 03:46:46< vultraz> and the fact that the deleters are specified as structs with operator().. 
20160913 03:47:59< vultraz> so I thought I could change scoped_resource to take a function in its constructor or something
20160913 03:48:06< vultraz> but then I remembered that unique_ptr/shared_ptrs also had deleteres
20160913 03:48:12< vultraz> so I wondered if it was worth it
20160913 03:48:21< vultraz> so I thought I'd see if surface could use one of those
20160913 03:48:25< vultraz> and then I ended up here :|
20160913 03:49:35< shadowm> Seems it's { SDL_Surface*, unspecified_type* -> { unspecified_type, unspecified_type } } in GCC 6.
20160913 03:50:19< shadowm> Where the last two unspecified_types are both native word-sized.
20160913 03:50:43< shadowm> Still seems like a waste to me.
20160913 03:50:45< vultraz> so I guess I *need* to use scoped_resource here
20160913 03:51:54< shadowm> If scoped_resource is going away you can just unpack the whole thing into the surface class.
20160913 03:53:18< vultraz> seem to be only 2 other direct usecases of it
20160913 03:53:43< vultraz> it should probably go away, yes
20160913 03:54:01< vultraz> along with scoped_array and scoped_ptr
20160913 03:54:35< vultraz> former of which is used in...tools\exploder_utils.cpp
20160913 03:54:37< vultraz> wow
20160913 03:56:48-!- irker961 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160913 04:00:09-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160913 04:01:51< vultraz> ok I'll unpack the functionality into the surface class
20160913 04:06:25< tad_> I'm headed to bed. I added a long design note to PR 775 which, I think, explains what's happening with [terrain_mask] in 1.12.6 and the current master, and where I think it should go. I hope it helps and I think once it's done and debugged it will be a nice feature.
20160913 04:17:49-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160913 04:38:10< vultraz> hm..
20160913 04:38:24< vultraz> how would I roll this functionality together..
20160913 04:47:08< shadowm> loonycyborg: Could you rebase your campaignd PR against master and merge? The bugs I reported seem fixed now.
20160913 04:48:03-!- Kwandulin [~Miranda@p200300760F2C7190484D1296889465D4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160913 04:48:09< shadowm> Or merge it into master directly, I don't know what our Glorious Leader's policy on rebase vs. true merge of branches (especially old ones with conflicts) is.
20160913 04:48:45< shadowm> loonycyborg: And also keep me informed of when this happens so I can rebuild it on baldras and keep an eye on the results.
20160913 04:49:41< vultraz> I'd rather something so old be rebased.
20160913 04:55:27< vultraz> Any chance of you seeing if the handled/halt thing fixes the gui2 filebrowser crash before 1.13.6?
20160913 04:56:55-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160913 04:59:37-!- Bonobo [~Bonobo@129.127.113.130] has joined #wesnoth-dev
20160913 05:02:12< shadowm> Perhaps.
20160913 05:05:49< shadowm> I forget I need a debug build for these things.
20160913 05:06:33< shadowm> Well, I guess having said that I can measure exactly how long it takes to build -O0 from scratch on 8 threads.
20160913 05:08:32< shadowm> While the system is under heavy load from another source.
20160913 05:08:59-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160913 05:09:00-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160913 05:09:24< vultraz> dammit
20160913 05:09:38< vultraz> I was unsuccessful 
20160913 05:09:51< vultraz> least it doesn't crash this time, but..
20160913 05:10:01< vultraz> nothing appears on-screen
20160913 05:10:15< vultraz> and it's 17 minutes every time I modify this file >_>
20160913 05:13:21< vultraz> inb4 you do full debug build in less time
20160913 05:14:26< shadowm> Who knows, the extra load is around 320% CPU usage from an overzealous IDE.
20160913 05:14:49< shadowm> So poor nanacore isn't exactly able to dedicate her full attention span to compiling Wesnoth.
20160913 05:16:40< shadowm> That took 8 minutes.
20160913 05:16:45< vultraz> :|
20160913 05:16:56< vultraz> A full debug build takes me around 25.
20160913 05:17:14< zookeeper> tad_, btw, there's no super convenient way to recall a unit to SW of the leader, but it's pretty simple to do [store_locations] [filter_adjacent_location] [filter] side,canrecruit=1,yes [/filter] adjacent=ne [/filter_adjacent_location] variable=foo [/store_locations] and then [recall] x,y=$foo.x,$foo.y
20160913 05:17:14< shadowm> Perhaps you're running out of RAM?
20160913 05:17:30< vultraz> i only have 8 gb and 4 cores
20160913 05:18:03< shadowm> Release builds are more expensive in terms of RAM and processing power to make, whilst debug builds are extremely cheap... except whenever an archiver or linker step takes place.
20160913 05:18:21-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160913 05:18:38< shadowm> Those are much more resource-demanding because, well, consider this:
20160913 05:20:09-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160913 05:21:23< shadowm> shadowm@nanacore git:feature/gui2-file-dialog-take-2 ~/src/wesnoth % du -ch `find build/debug -name \*.o` | tail -n 1
20160913 05:21:26< shadowm> 2.1G    total
20160913 05:22:29< shadowm> The resulting executables are 239 MB and 18 MB here, compared to 22 MB and 13 MB with -O3.
20160913 05:23:10< shadowm> But the linker needs to be able to put the entire thing in memory to stitch it together and drop the redundant bits.
20160913 05:24:31-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160913 05:25:58< shadowm> Okay, so this is annoying.
20160913 05:26:32< shadowm> I'm getting a segmentation fault when launching a release or debug build with `-de` in the command line, UNLESS gdb is attached.
20160913 05:26:58< shadowm> I guess I'll have to look at a core dump.
20160913 05:26:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 05:27:38< shadowm> This crash isn't coming from my code (which was pretty unlikely since it doesn't run at that point, anyway).
20160913 05:27:59< vultraz> :/
20160913 05:28:06< shadowm> http://pastebin.com/raw/TMj84aCn
20160913 05:28:31< vultraz> hm..
20160913 05:28:41< vultraz> well there were some changes to the gameloop recently
20160913 05:29:05< shadowm> frame 3.
20160913 05:29:13< shadowm> I mean 2.
20160913 05:29:19< midzer> is it in any case preferably to choose -O3 over -O2 for release builds?
20160913 05:29:19< shadowm> (gdb) p load_data
20160913 05:29:22< shadowm> $1 = std::unique_ptr<savegame::load_game_metadata> containing 0x0
20160913 05:29:28< vultraz> ah...
20160913 05:29:35< vultraz> yeah, definitely a recent issue, then
20160913 05:29:49< shadowm> std::unique_ptr<savegame::load_game_metadata> load_data = std::move(load_data_);
20160913 05:29:54-!- Bonobo [~Bonobo@129.127.113.130] has quit [Ping timeout: 265 seconds]
20160913 05:29:59< shadowm> Somehow this is a null pointer.
20160913 05:30:06< shadowm> Sometimes.
20160913 05:30:20< shadowm> Hopefully you're thinking the same thing I'm thinking.
20160913 05:30:41< vultraz> it could have a few causes
20160913 05:30:46< vultraz> I'll look into it later
20160913 05:30:54< shadowm> I'm thinking of a data race.
20160913 05:30:59< vultraz> hm
20160913 05:31:01< vultraz> possible
20160913 05:31:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160913 05:31:13< shadowm> This is actually pretty important and dangerous.
20160913 05:31:15-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160913 05:32:03< shadowm> (And just to confirm std::move isn't somehow hallucinating, yes, load_data_ also contains a null pointer.)
20160913 05:32:03< vultraz> I cannot look into it right now
20160913 05:33:00< shadowm> Now, maybe it is intended to be a null pointer sometimes, that I can't know (but why would it depend on the exact timing of the CPU cycles leading up to this code).
20160913 05:33:03< zookeeper> tad_, WRT "The grass is still at (6,6) but the leader appears at (1,1)" <- sounds like the kind of bug that is so clearly a bug that it doesn't warrant any kind of compatibility option to preserve in case someone was foolish enough to rely on it.
20160913 05:33:24< shadowm> If it were intended to be null someone forgot to add some checks against that case.
20160913 05:33:51< shadowm> Oh also.
20160913 05:34:11< shadowm> Why the hell is that std::move call there in the first place?
20160913 05:34:15< vultraz> ask gfgtdf
20160913 05:34:20-!- Bonobo [~Bonobo@129.127.113.130] has joined #wesnoth-dev
20160913 05:34:27< shadowm> The whole point of unique_ptr is that it can only be owned once at a time.
20160913 05:34:44< shadowm> I guess you want to transfer ownership of it, but why?
20160913 05:35:05< vultraz> That was introduced in dcd037e5302109d5943607173dff2c0684ffa38f
20160913 05:35:40< vultraz> i cannot debug more since right now i cannot get anything to show on my screen :|
20160913 05:36:39< vultraz> why do we even store surface refcounts if nothing checks them
20160913 05:37:05< shadowm> "Nothing."
20160913 05:37:18< vultraz> or is it checked internally in sdl?
20160913 05:37:21< shadowm> I guess you completely missed the part where I mentioned SDL_FreeSurface.
20160913 05:37:51< shadowm> <shadowm> It _seems_ like to SDL the refcount is kind of irrelevant as long as you don't go around calling SDL_FreeSurface before your external refcount reaches zero.
20160913 05:38:02-!- Bonobo [~Bonobo@129.127.113.130] has quit [Read error: Connection reset by peer]
20160913 05:38:12< shadowm> The implication is that SDL_FreeSurface does check the refcount, and guess what that release policy our surface class uses does.
20160913 05:38:29< vultraz> I see
20160913 05:40:11< vultraz> oh durrrrr
20160913 05:40:23< vultraz> void assign(SDL_Surface* surf) { assign(surf); } :|
20160913 05:40:35< vultraz> pretty sure I just made an infinite loop here
20160913 05:41:45< shadowm> Okay, right, load_data_ must contain a null pointer if the R-value reference version of operator= was used.
20160913 05:42:04< shadowm> Still, the receiver (load_data) shouldn't have a null pointer unless the source already held one.
20160913 05:42:24< shadowm> Unfortunately debugging this will be a PITA and it's not what I signed up for.
20160913 05:42:48< shadowm> So I'm going to play Russian roulette instead.
20160913 05:43:14< shadowm> And I already died on the first round.
20160913 05:43:48< shadowm> And the second and third rounds as well.
20160913 05:43:56< shadowm> I'm not going to look at that GUI2 dialog tonight then.
20160913 05:45:18< vultraz> Sadness
20160913 05:45:45< vultraz> i assume you don't want to go through the titlescreen
20160913 05:47:59< shadowm> Oh, okay, then it's not a data race, it's just plain breakage.
20160913 05:48:59< shadowm> I was starting to suspect I was barking at the wrong tree when I noticed that the game_launcher::load_data_ doesn't seem to be instantiated from a different thread.
20160913 05:49:26< shadowm> Okay, then I can work with the title screen workflow, even if it's highly inconvenient for what I'm about to do.
20160913 05:59:51-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160913 06:03:09< vultraz> Alright, I have a good idea how to proceed if this works.
20160913 06:05:33< shadowm> How do I C++.
20160913 06:06:24< vultraz> I wonder if surface should own the renderer directly
20160913 06:06:30< vultraz> or that should be in its own class
20160913 06:07:40< vultraz> AGGHHH
20160913 06:08:00< vultraz> SDL crash AGAIN
20160913 06:08:17< vultraz> god dammit I'll need a debug build won't I
20160913 06:10:56< vultraz> let't try this *one more time*
20160913 06:12:25< shadowm> I need to call gui2::tdispatcher::connect_signal() and give it a tsignal_function.
20160913 06:12:39< shadowm> I'm having trouble making an ad-hoc tsignal_function.
20160913 06:14:18< shadowm> What would the usual procedure be?
20160913 06:16:12< shadowm> Okay, shadowm, first step: fix your dozen unresolved name errors.
20160913 06:16:20< shadowm> Second step: use a lambda.
20160913 06:17:02< shadowm> Which is what you were already doing, albeit with a dozen unresolved types everywhere and the wrong callee in the body.
20160913 06:17:32< shadowm> http://pastebin.com/raw/jKaXeyRs
20160913 06:17:40< shadowm> Now figure out why it doesn't work.
20160913 06:18:14< shadowm> Or why it only works very rarely, apparently.
20160913 06:21:07< vultraz> how does it not work?
20160913 06:21:15< shadowm> I feel it has to do with the fact that callback_mouse_left_double_click_ has its own double click handler that sets handled to true.
20160913 06:21:15-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160913 06:21:41< shadowm> And I can't hook into said handler because it expects me to give it a single-argument function.
20160913 06:21:54< shadowm> vultraz: Here's how it doesn't work: by not working.
20160913 06:22:39< shadowm> By not ...
20160913 06:22:46< shadowm> s/callback_mouse_left_double_click_/ttoggle_panel/
20160913 06:22:59< shadowm> Massive mispaste-induced typo there.
20160913 06:23:23< shadowm> I don't even know why I pressed shift+insert instead of typing out the name of the thing.
20160913 06:23:51< vultraz> pretty sure you can pass a function with more than one argument to that
20160913 06:23:57< shadowm> No, you can't.
20160913 06:24:15< shadowm> Look at gui2::ttoggle_panel::set_callback_mouse_left_double_click().
20160913 06:24:44< shadowm> It wants a function that takes a twidget& and returns nothing.
20160913 06:25:39< vultraz> I am almost certain I have used set_callback_state_change (in ttoggle_button, declared in tselectable_) which also takes a twidget reference with a function with more than one argument
20160913 06:25:47< vultraz> I am almost *positive* I have done so.
20160913 06:25:52< shadowm> It's purposefully dumb so as to not require the caller to declare a function with the entire set of parameters.
20160913 06:26:08< shadowm> But it's also always there, serving as the first-level handler for the double click event.
20160913 06:26:40< shadowm> This is a ttoggle_panel, not a ttoggle_button.
20160913 06:26:50< shadowm> A ttoggle_button is not what is needed or wanted here.
20160913 06:27:11< vultraz> shadowm: try connecting it in position event::tdispatcher::front_child or front_pre_child
20160913 06:27:43< shadowm> Oh wait, that's a thing?
20160913 06:27:45< vultraz> yes
20160913 06:27:46 * shadowm facepalms.
20160913 06:28:03< vultraz> second argument to connect_signal
20160913 06:28:09< shadowm> Somehow I failed to notice the second half of that function's signature.
20160913 06:28:48< vultraz> also, *YES* I got the surface refactor working
20160913 06:29:22< shadowm> I believe front_pre_child should work for what I need.
20160913 06:31:19-!- irker864 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160913 06:31:19< irker864> wesnoth: Charles Dang wesnoth:surface_cleanup 3f3e098e3c35 / src/sdl/utils.hpp: Refactored use of util::scoped_resource out of surface struct (now class) https://github.com/wesnoth/wesnoth/commit/3f3e098e3c35ee6bb692ee7558db6eb8f93ea114
20160913 06:31:24< vultraz> That too *way* too long
20160913 06:31:35< vultraz> took*
20160913 06:32:48< vultraz> for the record, I'm still almost certain I've passed functions with more than just a twidget reference as their arguments to one of those setter functions 
20160913 06:33:07< shadowm> Fact check: you *can* use external refcounting types. It's just not guaranteed to work forever, and is also a waste of time and at least one native word-sized value.
20160913 06:33:41< shadowm> (Or more memory, depends on the exODODODODact implementation of shared_ptr.)
20160913 06:33:46< shadowm> *exact
20160913 06:33:50< vultraz> however, if you *really* need it to be exact, you could do []() (twidget& w) { another_function_with_more_arguments(w, stuff stuff); } 
20160913 06:34:05< shadowm> Yes, vultraz, I can do that.
20160913 06:34:07< vultraz> er, ignore that first extra ()
20160913 06:34:18< shadowm> Except I can't, because two of those arguments are unknown to me.
20160913 06:34:33< shadowm> I need them from the event handling pipeline, and ttoggle_panel won't give them to me.
20160913 06:35:18< vultraz> binding them with placeholders seems to work too
20160913 06:35:33-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160913 06:35:45< vultraz> see also: https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_options_helper.cpp#L248
20160913 06:35:55< shadowm> No, not really, not in this case. Here's why:
20160913 06:35:58< shadowm>   callback_mouse_left_double_click_(*this);
20160913 06:37:00< shadowm> That callback_mouse_left_double_click_ is a function object for the function I'm passing to ttoggle_pannel::set_callback_mouse_left_double_click().
20160913 06:37:19< vultraz> I see
20160913 06:37:24< shadowm> There's simply no way those parameters I need will reach me if my caller doesn't give them to me.
20160913 06:37:48< shadowm> Hence the need to bypass ttoggle_panel's trivial callback mechanism and talk to GUI2 directly.
20160913 06:38:10< shadowm> In the code you linked, connect_signal_mouse_left_click() does exactly that on account of it being a generic function.
20160913 06:38:40< shadowm> I'm essentially rolling out my own inline connect_signal_mouse_left_double_click() since there isn't one in existence yet.
20160913 06:38:56< vultraz> yeah, I get it
20160913 06:39:43< vultraz> using connect_signal directly isn't unheard of
20160913 06:40:49< shadowm> So, I _think_ using front_pre_child placement worked, although it also seems I've got a logic bug somewhere.
20160913 06:41:15< shadowm> Wait, no, it's just GUI2 being GUI2.
20160913 06:41:26< vultraz> what is the bug?
20160913 06:41:30< shadowm> Resizing the whole dialog when things change. Making it ludicrously large.
20160913 06:41:44< vultraz> ah that
20160913 06:41:57< shadowm> I thought it was the dialog returning to the caller and proceeding to the GUI1 version. Had to add a label and restart to make sure.
20160913 06:42:11< vultraz> yeah, no workaround yet
20160913 06:42:16< shadowm> I am seeing a logic bug now though.
20160913 06:42:29< vultraz> you'll have to manually truncate the filenames like I do in load game
20160913 06:43:21< shadowm> Hm, or the double click event isn't firing sometimes.
20160913 06:43:49-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160913 06:43:59< shadowm> Or at least it's not reaching my handler.
20160913 06:45:07< shadowm> Sigh.
20160913 06:45:34< shadowm> Let me make sure it's not GUI2 double click events being generally unreliable.
20160913 06:47:05< shadowm> Well, not within a dialog that returns on double click, no.
20160913 06:47:18< shadowm> It sucks that what I'm doing here is completely unique across GUI2.
20160913 06:48:03< shadowm> I've seen GUI2 miss single click events in quick succession when targeting different widgets, so I'd not be entirely surprised if double click was also subject to some kind of glitch.
20160913 06:48:20< vultraz> I can't think of any way this might be useful to you, but I added the ability to bind a bool function to a window as an exit hook
20160913 06:48:48< shadowm> (For example, go to the Campaigns menu, rapidly click between items (with a working mouse) and you should eventually miss an event.)
20160913 06:48:56< vultraz> it's evaluated on any close request and only closes the window if it's true
20160913 06:49:00< vultraz> might be useful to debuggin
20160913 06:49:02< vultraz> g
20160913 06:49:04< vultraz> dunno
20160913 06:49:12< shadowm> D:
20160913 06:49:21< shadowm> Debugging? What the hell.
20160913 06:49:34< shadowm> What you are telling me is that you have a much better way to implement this done already.
20160913 06:49:56< vultraz> the functions are set_exit_hook or set_exit_hook_ok_only
20160913 06:50:11< vultraz> latter only's evaluated if retval is OK
20160913 06:50:20< vultraz> latter's only*
20160913 06:51:50< shadowm> I have a feeling this would be deemed un-GUI2 by mordante but okay, let's see if I can spare me all the headaches of event handling using that instead...
20160913 06:52:02< shadowm> OTOH I just realized that this doesn't tell me what widget triggered the exit attempt.
20160913 06:52:35< shadowm> So I'd need to handle click on OK/Cancel buttons in addition to that.
20160913 06:52:48< shadowm> And keyboard Escape presses. And Enter.
20160913 06:52:54< shadowm> And Numpad Enter.
20160913 06:52:59< shadowm> /o\
20160913 06:53:14< vultraz> that's precisely the reason I implemented the exit hook :P
20160913 06:53:32< shadowm> Huh?
20160913 06:54:12-!- Kwandulin [~Miranda@p200300760F2C7190484D1296889465D4.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20160913 06:54:15< vultraz> when doing GUI2 mp create, I realized I needed a way to show the difficulty dialog on-exit if you selected a campaign
20160913 06:54:34< vultraz> rather than try to hook into every form of positive exit you described above, I implemented the exit hook
20160913 06:54:40< shadowm> You can record that a campaign was selected.
20160913 06:54:52< shadowm> I can't record that anything was selected here because something is ALWAYS selected.
20160913 06:54:53< vultraz> true
20160913 06:55:08< shadowm> I need to know whether something was double-clicked instead, and that's where the non-determinism happens.
20160913 06:55:36< shadowm> Because sometimes double-clicking doesn't invoke my handler whose first statement logs a message to stderr.
20160913 06:55:40< vultraz> maybe you can use return_value_id
20160913 06:55:54< vultraz> set a different id for the toggle panel
20160913 06:56:15< shadowm> Then how can I tell what retval is being used?
20160913 06:56:26< shadowm> Oh, get_retval(), okay.
20160913 06:59:09< vultraz> you might have to slightly alter the implementation of get_retval for that
20160913 06:59:22< shadowm> Uh why?
20160913 06:59:43< vultraz> not sure
20160913 06:59:57< shadowm> If I set my widget's retval to some magic number, get_retval() should give me that magic number back if my widget triggered the exit, shouldn't it?
20160913 07:00:22< vultraz> ah yes
20160913 07:00:44< vultraz> it's only if a string id is passed that it must match an existing retval
20160913 07:01:08< vultraz> a numbered retval (return_value = ) is simply returned
20160913 07:03:00< vultraz> however... I'm unsure whether the toggle panel will trigger an exist if return_value_id = "ok" is not used
20160913 07:03:49< shadowm> "It doesn't".
20160913 07:04:23< shadowm> Waaait.
20160913 07:04:25< shadowm> It should.
20160913 07:04:31< vultraz> you could always call window.close()
20160913 07:04:34< shadowm> I have the code right in front of me saying it should.
20160913 07:04:46< vultraz> well if you found a bug 
20160913 07:04:49< vultraz> do fix it
20160913 07:04:51< vultraz> brb off to store
20160913 07:05:01< shadowm> It also does that.
20160913 07:06:03< shadowm> I must've done something wrong.
20160913 07:08:51-!- atarocch [~atarocch@62.134.204.4] has joined #wesnoth-dev
20160913 07:08:52< shadowm> Hurr durr.
20160913 07:08:56< shadowm> I know what I did wrong.
20160913 07:09:14< shadowm> I forgot to restore the call to the second stage of my event handler.
20160913 07:09:30< shadowm> Or more accurately, wire it into the exit hook.
20160913 07:10:09< shadowm> Welll, call the first stage. And modify it so it isn't bound to the event handling pipeline.
20160913 07:10:53< shadowm> I love how I'm so invested into this that I have like 5 commits in the same branch all aptly described as "Stuff".
20160913 07:14:02 * shadowm hugs vultraz.
20160913 07:14:19< shadowm> This exit hook thing works like a charm. Thank you. ♥
20160913 07:15:10< shadowm> That solves all my problems so I don't need to worry about event handling ignoring me sometimes for no obvious reason.
20160913 07:15:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 07:16:18< shadowm> Now I wonder if I shouldn't set the retval on the listbox instead.
20160913 07:17:15< shadowm> Eh, I guess that's not a thing one can do anyway.
20160913 07:17:28< shadowm> Can't see any methods with 'retval' in them at least.
20160913 07:18:33< shadowm> Yep, even in WML retval seems to be a property of toggle panels, not listboxes. I guess I was remembering wrong.
20160913 07:18:54< vultraz> :D 
20160913 07:19:01< vultraz> Glad I mentioned it now
20160913 07:19:23< shadowm> In that case now I just need to figure out why my logic breaks horribly on the root of the fs hierarchy, and add support for Windows drives.
20160913 07:19:41< shadowm> And tidy up this massive mess.
20160913 07:19:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160913 07:20:11< shadowm> Oh, also, browsing the Wesnoth cache dir with this: not a good idea.
20160913 07:20:23< ancestral> Wow, hugs and hearts! What’s going on here?
20160913 07:20:26< ancestral> ;-)
20160913 07:20:31< shadowm> It slows down things to a crawl because of the massive amount of items and long labels.
20160913 07:21:01< vultraz> honestly I'd say disable browsing the cache dir.
20160913 07:21:15< shadowm> Can't really do that.
20160913 07:21:28< shadowm> This is supposed to be a generic file dialog without any special knowledge of what it's doing.
20160913 07:21:39< shadowm> vultraz: Do we have a simple mechanism to ellipsize labels? I feel like that'd solve most of the problem most of the time.
20160913 07:22:06< vultraz> https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/game_load.cpp#L131
20160913 07:22:10< shadowm> I mean using GUI2 WML or API calls as opposed to calling some string algorithm on each listbox item being pushed.
20160913 07:22:19< vultraz> I see
20160913 07:22:21< vultraz> no, not yet
20160913 07:22:37< shadowm> Meh.
20160913 07:23:06< shadowm> I seem to vaguely recall someone discovering that GUI2 labels had logic to ellipsize but it couldn't be triggered under normal circumstances.
20160913 07:23:53< vultraz> that is true
20160913 07:24:01< vultraz> the necessary function was never implemented
20160913 07:24:08< shadowm> The problem here and why I'm generally opposed to truncating strings, is that the individual glyphs can vary widly in size.
20160913 07:24:20< shadowm> Sometimes in both directions (think Zalgo).
20160913 07:26:38< shadowm> But it should work for reducing the performance impact of long file names on certain directories, at least.
20160913 07:26:59< shadowm> I don't suppose I can tell GUI2 to stop resizing everything all the time, though.
20160913 07:27:22< vultraz> there's an invalidate_layout_blocker
20160913 07:30:47< shadowm> Also, the dialog leaves trails behind when it resizes itself.
20160913 07:31:36< shadowm> Uh wow, I really have a lot of cache files.
20160913 07:31:59< shadowm> 5668.
20160913 07:32:05< vultraz> put set_restore(true) in the constructor 
20160913 07:32:13< vultraz> body
20160913 07:32:27< shadowm> Why isn't that a thing for all dialogs?
20160913 07:32:50< vultraz> ask Aginor 
20160913 07:33:04< vultraz> something to do with undrawing
20160913 07:33:13< shadowm> Do I have to? I thought you'd know since you know how to do it.
20160913 07:33:25< shadowm> This kind of thing should never be opt-in.
20160913 07:33:45< vultraz> he made it opt-in
20160913 07:33:50< shadowm> I don't mean the exact implementation, but rather the general concept of making it possible for a UI component to not break things
20160913 07:34:04< vultraz> I don't know why
20160913 07:34:16< Aginor> we generally don't want them all to restore themselves
20160913 07:34:26< shadowm> It'd be like if you had to manually ask the OS for a process id every time you start your program.
20160913 07:34:38< Aginor> and the entire restore logic breaks horribly when resizing things
20160913 07:34:55< shadowm> Why should they not always restore themselves?
20160913 07:35:36< Aginor> because restoring potentially stale data that is a composite of multiple different states will not always yield the correct results
20160913 07:36:49< shadowm> Okay, really, dialogs shouldn't have to know or care about any of this and things should just work out of the box however is best for them.
20160913 07:37:07< Aginor> depending on the background of the dialog (I kid you not), it should or should not be restored
20160913 07:37:17< Aginor> I fully agree with your statement above though
20160913 07:37:24< shadowm> My dialog has no idea where it's being called from.
20160913 07:37:39< shadowm> It might be from the editor. It might be from Preferences. There might be a game in progress, there might not.
20160913 07:37:51< Aginor> the entire redrawing concept needs to die a horrible death and we need to be able to selectively tell parts that they need to redraw
20160913 07:37:55< shadowm> It might be called from the title screen as well.
20160913 07:39:04< shadowm> Or from a variety of other places that are yet to come to need of this dialog's services.
20160913 07:39:51< shadowm> With this into consideration, I'm not going to include the workaround and I'll leave it to vultraz or someone else to decide what to do about the resizing trail.
20160913 07:40:52< shadowm> IS "Could not create a new folder at $path|. Make sure you have the appropriate permissions to write to this location." an appropriate message to show, syntax and style-wise?
20160913 07:41:35< shadowm> The GUI1 version just says "Creation of the directory failed.".
20160913 07:41:44< vultraz> yes
20160913 07:41:50< shadowm> (And yes, apparently I am calling them 'folders' now. Ugh.)
20160913 07:41:52< Aginor> indeed
20160913 07:42:08< Aginor> I think "folders" won the naming contest years ago :/
20160913 07:42:36< shadowm> I noticed KDE Dolphin enforcing that terminology relatively recently.
20160913 07:43:16< shadowm> At least it's pretty unlikely that anyone will invent new UI paradigms that will replace these with sillier terms.
20160913 07:43:25< shadowm> In this decade at least.
20160913 07:44:01< Aginor> don't type that out loud, someone might hear you
20160913 07:44:03< shadowm> Then again, we just witnessed the industry at large reverting to pre-90s icon design, so...?
20160913 07:44:11< Aginor> and be all like "challange accepted"
20160913 07:45:15< Aginor> vultraz: I sent a response to dave earlier
20160913 07:45:29< vultraz> ah, good
20160913 07:45:33< irker864> wesnoth: Charles Dang wesnoth:surface_cleanup dfba4355d025 / src/ (gui/core/canvas.cpp sdl/utils.hpp): Allow any surface to create its own SDL software (surface) renderer https://github.com/wesnoth/wesnoth/commit/dfba4355d02522c08f31431848543c3a2267d0fe
20160913 07:45:36< irker864> wesnoth: Charles Dang wesnoth:surface_cleanup 69c02d450a3d / / (6 files in 4 dirs): Split drawing primitives helpers out of the GUI2 canvas and into their own file https://github.com/wesnoth/wesnoth/commit/69c02d450a3d1480fa1ecf8059e07a4724cc642b
20160913 07:47:05< vultraz> possibly should move some more of the logic out of the canvas
20160913 07:55:45-!- boucman_work [~boucman@113.15.204.77.rev.sfr.net] has joined #wesnoth-dev
20160913 08:16:17-!- Kwandulin [~Miranda@p200300760F2C71AF4CA9EA4342083AAD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160913 08:16:22-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160913 08:35:41-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20160913 08:51:09-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160913 08:57:26-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160913 08:58:12< vultraz> blah
20160913 08:58:19< vultraz> not really satisfied with what I came up with here
20160913 09:03:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 09:06:35< vultraz> Aginor: around?
20160913 09:07:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20160913 10:28:31-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Ping timeout: 265 seconds]
20160913 10:51:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 10:52:44-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160913 10:55:39-!- irker864 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160913 10:56:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160913 11:09:19-!- Bonobo [~Bonobo@2001:44b8:254:3200:1d32:d004:288c:3554] has joined #wesnoth-dev
20160913 11:12:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 11:17:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160913 11:20:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160913 11:48:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 11:53:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160913 12:05:43-!- irker598 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160913 12:05:43< irker598> wesnoth: Charles Dang wesnoth:surface_cleanup 9ace2d3dff2a / src/sdl/ (renderer.cpp renderer.hpp): Reduce renderer log level (accidentally had it set to error) https://github.com/wesnoth/wesnoth/commit/9ace2d3dff2a0c5e14cde27a64aed5e70d09ccb6
20160913 12:12:18-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160913 12:12:28-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160913 12:16:03< vultraz> loonycyborg: will network_worker.*pp still be used after the campaignd pr is merged? if not, will it be removed?
20160913 12:16:55< vultraz> asking since i'd like to remove scoped_resource, but there's a usecase of it in network_worker.cpp. if that file's going away soon I can just ignore it.
20160913 12:16:57< loonycyborg> It won't be, I'm not sure I've removed it though
20160913 12:17:18< loonycyborg> ok ignore it then
20160913 12:18:13< loonycyborg> hmm
20160913 12:18:31< loonycyborg> there was some change about game_config::flag_rgb
20160913 12:18:55< loonycyborg> which makes trouble for me when resolving conflict
20160913 12:21:24-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has joined #wesnoth-dev
20160913 12:21:26< vultraz> hmm.. this other case of scoped_resource is in posix system-only code... I better let someone like shadowm handle it
20160913 12:21:42< vultraz> (or another non-windows user)
20160913 12:22:33< vultraz> anyone not on windows: if you can possibly convert desktop/version.cpp:89 to a unique_ptr that'd be helpful.
20160913 12:24:49< loonycyborg> oh, I derped and omitted definition of that var, cause it was next to UInt32 converted to uint32_t
20160913 12:29:47< loonycyborg> I might look into desktop/version.cpp later
20160913 12:53:00-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has quit [Quit: Leaving]
20160913 12:58:38< vultraz> thanks
20160913 13:05:51-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160913 13:07:38-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160913 13:43:57< mattsc> zookeeper: out of curisoity, do you consider an own unit blocking the exit hex of a tunnel a feature or a bug?
20160913 13:44:14< mattsc> Same question to everybody else, of course, but I am specifically trying to rouse zookeeper.  :P
20160913 13:44:21< irker598> wesnoth: Charles Dang wesnoth:campaignd_asio a1f688455505 / src/ (13 files in 6 dirs): Refactor uses of boost::tuple to std::tuple or std::pair as appropriate https://github.com/wesnoth/wesnoth/commit/a1f68845550528a611726ae45416232a8136f4ea
20160913 13:44:24< irker598> wesnoth: Charles Dang wesnoth:campaignd_asio 23c2dd0c9480 / src/campaign_server/campaign_server.hpp: Un-constify a unique_ptr consted in error https://github.com/wesnoth/wesnoth/commit/23c2dd0c94806e57b414e9f344f7261a8bba9736
20160913 13:44:27< irker598> wesnoth: Gregory A Lundberg wesnoth:campaignd_asio 10e008a84114 / src/units/map.cpp: Missing newline on stderr https://github.com/wesnoth/wesnoth/commit/10e008a841145d0b669058203ebb011465a254e5
20160913 13:44:29< irker598> wesnoth: Charles Dang wesnoth:campaignd_asio 0631dfdd00c4 / src/units/map.cpp: Merge pull request #712 from GregoryLundberg/GL_newid https://github.com/wesnoth/wesnoth/commit/0631dfdd00c4cd79c37f0b087739a191047bccd2
20160913 13:44:32< irker598> wesnoth: Charles Dang wesnoth:campaignd_asio 771936ad9544 / src/tests/ (test_commandline_options.cpp test_formula_core.cpp test_mp_connect.cpp): Update unit tests https://github.com/wesnoth/wesnoth/commit/771936ad954428569b328eb5cdf9d0437bd88aa5
20160913 13:44:35< irker598> wesnoth: Jyrki Vesterinen wesnoth:campaignd_asio c2abe3a6220b / / (8 files in 5 dirs): Kill floating_point_emulation.hpp with fire (#713) https://github.com/wesnoth/wesnoth/commit/c2abe3a6220b00b39b0238057af8734c6cc80fc6
20160913 13:44:36-!- mode/#wesnoth-dev [+q *!*@uruz.ai0867.net] by ChanServ
20160913 13:44:36-ChanServ:#wesnoth-dev- loonycyborg quieted *!*@uruz.ai0867.net
20160913 13:44:54< loonycyborg> mattsc: can't allied units move through each other anyway?
20160913 13:45:06< mattsc> loonycyborg: thanks for quieting that
20160913 13:45:15< mattsc> loonycyborg: yes, they can, but they cannot in tunnels
20160913 13:45:23< mattsc> so in my opinion, that’s a bug
20160913 13:45:45< mattsc> As in, if there’s one of your own units on the tunnel exit, you can’t move through it
20160913 13:46:14< mattsc> Worse than that, the pathfinder shows it as if it could go through, and then the unit on the exit hex acts like an ambusher to the moving unit
20160913 13:46:32< mattsc> That part is definitely a bug (and it wreaks all kinds of havoc with AIs)
20160913 13:46:54< loonycyborg> seems like a bug indeed
20160913 13:47:14< mattsc> Personally, I would simply change it that the unit can move through — and I just checked the code, that’s actually super easy to do.
20160913 13:47:22< zookeeper> just a fwe minutes...
20160913 13:47:28< mattsc> no worries
20160913 13:47:36< mattsc> But the other option would be to:
20160913 13:47:57< mattsc> 1. Adjust the pathfinding code so that it does not show hexes on the other side of the tunnel as reachable
20160913 13:48:33< mattsc> 2. Add an option to the tunnel tag with which to trigger this behavior on and off (and I don’t care in that case which way we keep the default)
20160913 13:49:28< mattsc> 1. and 2. a two steps of Option 2; I said that kind of confusingly  :P
20160913 13:49:35< DeFender1031> mattsc, there's also the question of whether you can attack through tunnels
20160913 13:49:55< DeFender1031> (meaning, an enemy is standing on the tunnel exit)
20160913 13:50:26< mattsc> DeFender1031: can they at the moment?
20160913 13:50:30< DeFender1031> nope
20160913 13:51:13< mattsc> Okay; that would be my gut feeling as what I’d expect the behavior should be, but I have no personal objection to adding the latter as another option.
20160913 13:51:15< zookeeper> mattsc, i think we discussed that sometime before? i think there's no one right answer to that, so i'd actually suggest an option for it
20160913 13:51:17< DeFender1031> but what i'm saying is that there ought to be options (in wml) as to what behaviors of an adjacent hex are displayed by a tunnel
20160913 13:52:12< mattsc> zookeeper: yes, it’s come up before, but I do not remember exactly who weighed in and what the opinions of those who did were.
20160913 13:52:35< DeFender1031> behaviors of adjacent hexes: 1. can attack from them 2. zoc 3. allies with enough movement can move through if occupied
20160913 13:52:37< zookeeper> mattsc, unless you can already achieve the blocking effect by the tunnel's filters, in which case you could just change it to not block
20160913 13:52:42< mattsc> zookeeper: okay; I was afraid you’d say that, because now I need to figure out how to do that  ;)
20160913 13:52:44< DeFender1031> there's probably more
20160913 13:53:04< mattsc> zookeeper: ooo, I like that
20160913 13:53:04< DeFender1031> but i think ideal would be options for whether each of these behaviors is active for such
20160913 13:53:20< zookeeper> mattsc, i'll dig up the previous discussion, just a moment...
20160913 13:55:33< mattsc> DeFender1031: I agree that that can be done and would probably be useful for some use cases; I am not sure whether I am the right person to do this (I am semi-illiterate when it comes to C++ code).
20160913 13:55:36< zookeeper> well, nothing too interesting there
20160913 13:56:00< DeFender1031> mattsc, fair enough
20160913 13:56:13< mattsc> Which is why I like that last option zookeeper suggested, because it’s very simple to code (essentially all you have to do is remove the check for the unit on the exit hex from the code)
20160913 13:56:42< zookeeper> so yes, if you change tunnels to not block, it seems like you can trivially simulate the current blocking behavior with [tunnel] [target]
20160913 13:56:43< DeFender1031> mattsc, my point was more that, as they stand now, tunnels are hacks in the code which are sort of considered adjacent and sort of not (teleportation ability as well)
20160913 13:56:52< mattsc> It also appeals to my general preference for keeping everything as simple as possible
20160913 13:57:08< DeFender1031> right
20160913 13:57:34< DeFender1031> oh yeah
20160913 13:57:35< mattsc> DeFender1031: yeah, agreed
20160913 13:57:39< DeFender1031> vision through tunnels is another one
20160913 13:57:53< DeFender1031> currently, there is none.
20160913 13:57:59< DeFender1031> an option for that would be nice too
20160913 13:58:17< mattsc> DeFender1031: yeah, sounds reasonable
20160913 13:58:24< mattsc> zookeeper: let me just try that
20160913 14:00:26< DeFender1031> for example, i've got a map which simulates a 10-storey castle using tunnels for the stairs. Vision and attacking up or down stairs should be possible, and in fact, if there's shroud, the castle will not be explorable without some kind of extra hack.
20160913 14:00:29< zookeeper> [tunnel] is used in a whole lot of add-ons though, not sure how likely this would adversely affect them
20160913 14:00:54< DeFender1031> zookeeper, the question is whether anyone relies on th blocking behavior
20160913 14:00:54< mattsc> zookeeper: if we change the main behavior, you mean?
20160913 14:01:07< zookeeper> DeFender1031, yes, was that not my question? :p
20160913 14:01:14< zookeeper> mattsc, yes
20160913 14:01:17< mattsc> zookeeper: I know of at least one scenario where the current behavior is a serious problem.
20160913 14:01:37< DeFender1031> zookeeper, you did that thing that Data from star trek does.
20160913 14:01:49< mattsc> But yes, the other way around probably also exists.
20160913 14:02:10< zookeeper> DeFender1031, well that is a flattering comparison
20160913 14:02:17< zookeeper> not sure what exactly you mean though :p
20160913 14:02:24< DeFender1031> which is why my suggestion to properly solve it would be additional option flags with the default being the current behavior.
20160913 14:03:31< zookeeper> yeah i don't have anything against making it an option, with current behavior as the default
20160913 14:03:50< zookeeper> that's always the safest route
20160913 14:03:54< DeFender1031> zookeeper, the running gag where he'll say like "the sensors are picking up small thermal areas and carbon dioxide emissions indicitave of combustion", and wesley or whoever will say "you mean campfires", and he'll ask "is that not what I just said?"
20160913 14:04:12< mattsc> zookeeper: but much harder to code  ;)
20160913 14:04:12< zookeeper> oh
20160913 14:04:51< mattsc> zookeeper: http://pastebin.com/EQmZhbpr  — as expected, that lets bowmen move through the tunnel, and not spearman, when the exit hex is occupied
20160913 14:05:34< mattsc> But if we want an option, then there’s a lot more work to be done ...
20160913 14:06:12< zookeeper> does that entail some work other than just laboriously passing the extra parameter all over the place?
20160913 14:07:29< mattsc> Well, it means adding the parameter (which I don’t know how to do but should not be too hard to figure out), adjusting the pathfinder to consider both cases, and the same for the move execution (the latter I know already how to do, once I figure out how to get the parameter passed there).
20160913 14:07:37< mattsc> So, no, nothing prohibitive, I think.
20160913 14:08:04< mattsc> I’ll look into it.
20160913 14:09:01< mattsc> And once I have done that, I’ll probably have a better feeling for how hard the options DeFender1031 suggested will be to do.
20160913 14:11:10< mattsc> Hmm, the pathfinding already works correctly for teleporting, of course, so I can probably just look up how it’s done there.
20160913 14:12:12< zookeeper> i hope there was some technical reason tunnels were implemented this way originally, and it wasn't just due to sloppy design
20160913 14:15:05< mattsc> zookeeper: it’s clearly done deliberately as that part of the code serves no other purpose.
20160913 14:15:21< mattsc> But I cannot find any reason why it has to be done like that.
20160913 14:16:48< DeFender1031> I would imagine that it was just a misguided thought of how they should practically work
20160913 14:17:53< DeFender1031> like a "you can't materialize in space already occupied by something else"
20160913 14:20:17< zookeeper> possibly
20160913 14:20:45< mattsc> I’m currently trying to see which commit introduced the code block doing the check.
20160913 14:21:01< mattsc> It’s a bit of a pain, because that files got refactored several times.
20160913 14:22:30-!- Kwandulin [~Miranda@p200300760F2C71AF4CA9EA4342083AAD.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160913 14:23:32-!- atarocch [~atarocch@62.134.204.4] has quit [Ping timeout: 240 seconds]
20160913 14:24:20< mattsc> zookeeper, DeFender1031: I found this: https://github.com/wesnoth/wesnoth/commit/5bbdeb7b2a4
20160913 14:24:32-!- irker598 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160913 14:24:42< mattsc> But that is not how the code looks at the moment, so something got change somewhere in between.
20160913 14:26:18< DeFender1031> mattsc, though that seems to presume that an ally-blocked destination should be untraversible.
20160913 14:26:40< mattsc> DeFender1031: right - which I personally disagree with
20160913 14:27:13< DeFender1031> as do i.
20160913 14:28:02< mattsc> And here’s the commit that introduced the current code:
20160913 14:28:03< DeFender1031> were it not for the need for backwards-compat, i'd say that a tunnel should, by default, act exactly like the hexes are adjacent.
20160913 14:28:05< mattsc> https://github.com/wesnoth/wesnoth/commit/b2674b7089ed78a9efd9a9a4d18ccec166410fdc#diff-db869def8f9edca87c157f26f4a1d25bR3021
20160913 14:28:28< mattsc> DeFender1031: agreed
20160913 14:28:56< DeFender1031> and doing that would solve a lot of issues, such as making an impossible move to a nonvisible destination
20160913 14:29:07-!- loonycyborg [~loonycybo@wesnoth/developer/loonycyborg] has quit [Ping timeout: 252 seconds]
20160913 14:29:12< DeFender1031> and from there, other options could have been added on
20160913 14:29:28< DeFender1031> but no use in crying over existing code.
20160913 14:29:32< mattsc> Right.
20160913 14:29:47< mattsc> Bottom line is, I am going to look into adding that option.
20160913 14:29:55< mattsc> And leaving the default as is.
20160913 14:30:24-!- Elvish_Hunter [~elvish_hu@wesnoth/developer/elvish-hunter] has quit [Ping timeout: 276 seconds]
20160913 14:30:43< mattsc> I’ve previously asked the author of the scenario where I know this casues a significant problem in a PM and he’s okay with that solution too.
20160913 14:32:58< zookeeper> DeFender1031, exactly like the hexes are adjacent with one notable exception: attacking :P
20160913 14:33:14< zookeeper> and, arguably, recruiting
20160913 14:33:31< zookeeper> and adjacent-affecting abilities etc
20160913 14:33:40< mattsc> Ooo, remote recruiting!
20160913 14:33:42< zookeeper> well, a lot of things i guess :>
20160913 14:34:47-!- loonycyborg [~loonycybo@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20160913 14:35:14< DeFender1031> i think the distinction is pathfinding. If it's something that's involved in paths (movement, vision, etc.) then the behavior by default ought to have been the same. If it's something that's involved in actually being next to each other, the default should have been not.
20160913 14:35:30< mattsc> zookeeper: on a different topic, here’s your biweekly reminder about the assassin squad AI  :D
20160913 14:35:43< DeFender1031> (but again, i think all of those things ought to have options. and remote recruiting sounds pretty interesting.)
20160913 14:36:41< zookeeper> mattsc, yeah i'm really just waiting for tad's HttT PR to go in first before i commit those kinds of changes
20160913 14:36:58< mattsc> zookeeper: great
20160913 14:37:52-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160913 14:42:45-!- Elvish_Hunter [~elvish_hu@wesnoth/developer/elvish-hunter] has joined #wesnoth-dev
20160913 14:42:46< tad_> zookeeper: I've been thinking about those changes for HttT supporting ;cl .. I think there are three areas. First: Li'sar .. lame and should be removed. Second: heros coming back instead of re-creating .. shows I didn't know [unit] implied [recall] and probably can be done better but the idea I'm going for, it turns out, is how it's supposed to work.  Finally, [kill] before [unit]. My impression is that's the real issue.
20160913 14:42:50< zookeeper> tad_, btw, there's no super convenient way to recall a unit to SW of the leader, but it's pretty simple to do [store_locations] [filter_adjacent_location] [filter] side,canrecruit=1,yes [/filter] adjacent=ne [/filter_adjacent_location] variable=foo [/store_locations] and then [recall] x,y=$foo.x,$foo.y
20160913 14:43:52< tad_> zookeeper: That's for LoW and, as needed there, so far, actually, it's pretty easy. Doing it however ran up against the buggy/disabled [terrain_mask] code.
20160913 14:44:22< zookeeper> tad_, i just don't see how it's a worth hacking in workarounds in scenarios for the possibility of getting some duplicate id units if you mess with debug mode? i mean, it's not like having duplicate id's makes the game explore or anything AFAIK.
20160913 14:44:34< tad_> zookeeper: So I wanted to talk about the [kill][unit] thing and decide if it's a workaround for a bug 
20160913 14:45:51< tad_> The issue has been raised before. There are a number of ways to intentionally create a duplicate id. But I view [unit] doing it as a bug, especially since [unit] does do [kill] but only for units on the recall list.
20160913 14:46:26< zookeeper> well it's certainly a workaround... although whether it's a "bug" or not is rather unanswerable IMO.
20160913 14:46:28< tad_> So, would it not make more sense to modify the implicit [kill] in [unit] to include on-map duplicates of the id?
20160913 14:46:57< zookeeper> implicit [recall] you mean?
20160913 14:48:35< tad_> Actually, maybe that is the issue. When I do [unit] I expect an imperative. "Create a unit". The implicit [recall] was, frankly, unexpected. I can see _why_ it's there and maybe I just never realized the documentation was telling me it was doing that.
20160913 14:49:43< mattsc> zookeeper: funny, just noticed that the teleoport ability used by the Silver Mage uses the [not][filter][/filter][/not] thingy in the [target] definition.
20160913 14:50:11< tad_> As to whether it "blows up" .. no I've not see a hard crash. But the wiki says, and it does appear, that things go awry. Which unit is affected becomes unknowable.
20160913 14:50:24< mattsc> So the difference in behavior actually comes from the WML, not the C++ code.  Which means I can’t copy that ...
20160913 14:50:31< mattsc> Oh well.
20160913 14:51:02< zookeeper> tad_, i don't really see a good way to prevent duplicate id's if the scenario spawns a unit with an id that an existing unit already has... i mean, you can 1) refuse to create the new unit or 2) ignore the new unit and just "move" the existing unit to its location, but both of those seem like they'd be bigger problems than the one they try to solve.
20160913 14:52:36< zookeeper> mattsc, right
20160913 14:52:55< zookeeper> tad_, i do find the implicit [recall] pretty weird (and yes it seems to have went undocumented)
20160913 14:53:06< zookeeper> i don't even know for how long it was existed
20160913 14:53:10< zookeeper> s/was/has
20160913 14:54:05< zookeeper> in a way it makes sense and i'm not advocating for trying to remove it or anything
20160913 14:54:45< DeFender1031> it seems that this problem should never be encountered... you should know what your code is doing enough to not encounter this, no?
20160913 14:55:27< tad_> zookeeper: Actually, the implicit [recall] coupled with the fixed [filter_recall] will probably make a huge difference to campaigns like DM .. when and if I get around to taking a look at the store/unstore mess.
20160913 14:57:11< zookeeper> DeFender1031, this is about jumping across scenarios via debug mode
20160913 14:57:30< DeFender1031> zookeeper, ah. fair.
20160913 14:57:48< zookeeper> like going from scenario 5 to scenario 2 and already having the unit you'll encounter again... and then they have the same id
20160913 14:58:24< DeFender1031> that seems like something that debug mode should not do...
20160913 14:58:53-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160913 14:59:19-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160913 14:59:31< tad_> Personally, I would advocate an error and adding a flag to [unit] to decide the issue. But if it is JUST in debug then I'm fine with simply stating the programmer is resposible for cleaning up his mess as he's debugging.
20160913 15:00:30-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160913 15:02:49< tad_> So, I'm pulling the commit but the issue of duplicates remain so it's possible we'll eventually find we have to face it in non-debug code.
20160913 15:03:00< zookeeper> sounds perfectly reasonable to print a warning (even a user-visible one, at this point; the "id's should be unique" thing has been in for a long time) when creating or unstoring a unit which results in there being a duplicate
20160913 15:04:07< zookeeper> adding a new [unit] flag for something like that feels fundamentally icky, since pretty much the only purpose is for it to act as a workaround for messing with debug mode
20160913 15:04:16< tad_> Yeah, I can force one by storing and modifying the variable. So there's a lot of ways and likely some we'll not think of if we actually decide to take a run at fixing it.
20160913 15:05:05< tad_> zookeeper: "messing with debug mode" .. I view it as "at this time, the only reason we know if messing with debug mode" but who knows what lurks in UMC ...
20160913 15:05:35-!- Bonobo [~Bonobo@2001:44b8:254:3200:1d32:d004:288c:3554] has quit [Quit: Leaving]
20160913 15:05:53< tad_> And I agree on "icky"
20160913 15:05:54< zookeeper> well in this case nothing can lurk in UMC except mistakes people make
20160913 15:06:45< zookeeper> if someone for example makes a circular campaign where you can encounter the same units again and get duplicate id's, that's just programmer error on the author's part
20160913 15:06:49-!- Kwandulin [~Miranda@p200300760F2C71AFA5E11E5B0C2AC803.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160913 15:07:02< zookeeper> just like if they simply spawn two units with identical id's
20160913 15:08:05< tad_> So, neither you nor I don't like the Li'sar stuff, the [kill][unit] is a workaround for a WONT-FIX and can be fixed by hand, if needed, and I'd do the heros differently if I re-wrote that commit today. So POOF! Give me a while to yank and push.
20160913 15:08:22< zookeeper> all right
20160913 15:09:32< zookeeper> i got up early so i'll take a nap in the meanwhile :J
20160913 15:11:45-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Ping timeout: 265 seconds]
20160913 15:12:15-!- Jetrel_bot [~Jetrel@ec2.happyspork.com] has quit [Ping timeout: 265 seconds]
20160913 15:12:15-!- Greywhin1 [~Greywhind@c-71-232-29-126.hsd1.ma.comcast.net] has quit [Ping timeout: 265 seconds]
20160913 15:12:23< tad_> Yeah. No conflicts from the yank. I want to do a quick run-through to be sure nothing broke badly and I'll push. 
20160913 15:12:28-!- travis-ci [~travis-ci@ec2-54-145-149-0.compute-1.amazonaws.com] has joined #wesnoth-dev
20160913 15:12:29< travis-ci> wesnoth/wesnoth#10898 (campaignd_asio - 1c90221 : loonycyborg): The build has errored.
20160913 15:12:29< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159597656
20160913 15:12:29-!- travis-ci [~travis-ci@ec2-54-145-149-0.compute-1.amazonaws.com] has left #wesnoth-dev []
20160913 15:12:58-!- Greywhind [~Greywhind@c-71-232-29-126.hsd1.ma.comcast.net] has joined #wesnoth-dev
20160913 15:13:51-!- Jetrel_bot [~Jetrel@ec2.happyspork.com] has joined #wesnoth-dev
20160913 15:14:10< tad_> vultraz: Any chance of getting you to take a look at the titlescreen resizing? Or should I pester celmin?
20160913 15:17:05-!- mode/#wesnoth-dev [-q *!*@uruz.ai0867.net] by ChanServ
20160913 15:23:24-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160913 15:27:02-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160913 15:29:59-!- gfgtdf [~chatzilla@x4e363432.dyn.telefonica.de] has joined #wesnoth-dev
20160913 15:33:03-!- boucman_work [~boucman@113.15.204.77.rev.sfr.net] has quit [Remote host closed the connection]
20160913 15:38:41< DeFender1031> what's this talk about Li'sar?
20160913 15:39:04-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160913 15:39:15< DeFender1031> tad_, ^^
20160913 15:39:19< bumbadadabum> vultraz: Can we disable some of the themes in-game?
20160913 15:39:39< bumbadadabum> because the widescreen and unitbox themes straight-up don't work at the moment
20160913 15:40:01-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160913 15:42:01< tad_> DeFender1031: What I did to the unit to make it behave like the other heros when she changes sides. Mainly for debug stuff, but (I just noticed) a slight change in how the unit is managed during the victory process, mainly having to do with what's on-screen when you press End Scenario
20160913 15:42:35< celticminstrel> Huh, DeFender1031 is talking in here?
20160913 15:43:01< DeFender1031> celticminstrel, is this a problem?
20160913 15:43:03-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160913 15:43:08< celticminstrel> Nope.
20160913 15:43:22< tad_> celticminstrel: Hit a glitch on the titlescreen. Wanna look at it or ignore it?
20160913 15:43:28< DeFender1031> tad_, ah, phew. I thought when you said "don't like the li'sar stuff" you were talking story-wise.
20160913 15:44:06< DeFender1031> and i was very confused as to how at this point someone could suggest removing a main character :P
20160913 15:44:26< celticminstrel> What kind of glitch?
20160913 15:44:26< tad_> DeFender1031: the subject was a rather large commit amid a stream of about 60 others fixing things in HttT and whether it should be kept, fixed or scrogged. It's scrogged.
20160913 15:45:07< DeFender1031> celticminstrel, usually the conversation in here is too codebase-specific for me to know what's going on at this point in my journey, but i happened to notice some discussion which was less so and, as usual, I had an opinion :P
20160913 15:46:09-!- Kwandulin [~Miranda@p200300760F2C71AFA5E11E5B0C2AC803.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160913 15:46:22< tad_> celticminstrel: After clearing cache etc and a make clean/make all .. the window was maximized but it paints smaller and leaves garbage (issue 1) and to fix it I restore window to normal but the buttons don't repaint and are off the edge (issue 2) so I close the program (X works, at least) and reopen and it repaints and all is well
20160913 15:49:45< tad_> celticminstrel: To test, maximize wesnoth (not full screen, maximized) quit, clear cache/config/local/etc like it's a brand-new install .. BUT the window manager remembers the window state (not wesnoth, scrogged it's memory) so wesnoth uses a default and the manager uses the last-known .. and they don't match
20160913 15:50:14< celticminstrel> BTW, about the mask thing, did you consider one parameter with three values rather than two boolean parameters?
20160913 15:50:44< celticminstrel> This problem sounds really weird.
20160913 15:51:21< celticminstrel> When you say the window is maximized, is that different from fullscreen?
20160913 15:51:33< tad_> celticminstrel: It was. testing it was hard because I had to figure out what changed, what didn't and could not test some cases because of the mess
20160913 15:51:56< celticminstrel> Oh, you already answered that.
20160913 15:52:24< tad_> window states: minimized, normal, maximized and full-screen. Buttons in titlebar by "X" do min/max/norm and wesnoth has to do full-screen internally 
20160913 15:54:43< tad_> The only way a mortal would hit this issue that I can think of would be to un-install wesnoth and re-install, and tell un-install to remove all files and folders (if that's an option).
20160913 15:54:53-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160913 16:01:02 * tad_ sighs. I hate merge conflicts. Such a pain to fix and wipe the fingerprints off the window sill when leaving the scene of the crime.
20160913 16:03:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 16:03:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160913 16:03:15< DeFender1031> "wesnoth has to do full-screen internally" <-- Actually, in KDE (1) You can use KDE's window fulscreening to do it and (2) I have multiple monitors and if I so much as click the option in wesnoth to go fullscreen, it blows up my entire display.
20160913 16:03:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 16:04:39< DeFender1031> No idea what combination of circumstnces causes that though, nor whether it's some issue with wesnoth or with KDE, or with X, or with my specific graphics card's specific drivers.
20160913 16:05:01< DeFender1031> I just avoid the issue by never clicking that option and using KDE to fullscreen instead.
20160913 16:05:04< tad_> DeFender1031: then that's a bug and you should pester someone about it here or on GNA. I've seen the same issue on Windows and the solution is to query the monitor being used and use its metrics BEFORE going full-screen. 
20160913 16:05:36< DeFender1031> tad_, i assumed it wasn't solely wesnoth's bug and would be too annoying to fix.
20160913 16:05:47< DeFender1031> (and i have a workable workaround)
20160913 16:06:13< tad_> DeFender1031: it's actually a common problem and problems don't get fixed if nobody raises their hand about them
20160913 16:07:33< DeFender1031> tad_, if you want me to be really annoying and pester you guys about every bug i come across, i would be more than happy to oblige. This one is, in fact, one of the ones about which i care the least.
20160913 16:07:59< celticminstrel> I feel like it might be an SDL bug rather than a Wesnoth bug, though.
20160913 16:08:01< tad_> but, yeah, it has to be fixed by the program. BTW, on windows you can also hit the issue maximizing. I'd expect different X managers would have different issues, too
20160913 16:08:35-!- irker231 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160913 16:08:35< irker231> wesnoth: loonycyborg wesnoth:master fe07bf500e98 / src/desktop/version.cpp: Replace custom scoped_resource with unique_ptr https://github.com/wesnoth/wesnoth/commit/fe07bf500e985ef4d1fa86abd4193c06378e2876
20160913 16:08:37< celticminstrel> For the record, Wesnoth's fullscreening on the Mac leverages the standard Mac fullscreen mode (meaning other monitors go grey, at least on 10.7).
20160913 16:08:44< tad_> DeFender1031: well, I feel at times I'm over-pestering :P
20160913 16:08:51< DeFender1031> more troubling to me is how images which extend past the current hex are iffy, the fact that image offsets don't properly account for the zoom level and thus end up in the wrong place, etc.
20160913 16:09:17< loonycyborg> vultraz: I committed a change replacing scoped_resource with unique_ptr
20160913 16:10:06< DeFender1031> tad_, i tend to try NOT to pester, as I know what it's like to do volunteer work and have people unsatisfied with my progress
20160913 16:10:19< tad_> celticminstrel: could be an SDL bug .. it's certainly a Windows bug when maximize crosses monitors .. but it's usually something you can workaround
20160913 16:10:41< celticminstrel> Maybe. I have no idea how you would, though.
20160913 16:11:01< gfgtdf> loonycyborg: do you know why we had scoped_resource in the first plce? I mean even before unique_ptr we coudl have used boost:scoped_ptr i'd think.
20160913 16:11:25< DeFender1031> tad_, honestly, the reason i started lurking in this channel is to hopefully learn the ropes and be able to join the team and some day fix any issues i come across myself.
20160913 16:11:27< tad_> celticminstrel: Look for a query current monitor function and a query monitor metrics function. Windows has 'em so I'd presume SDL supports 'em somewhere
20160913 16:11:30< loonycyborg> gfgtdf: no idea, it was really long time ago
20160913 16:11:46< celticminstrel> Probably.
20160913 16:12:05< loonycyborg> does boost::scoped_ptr support custom deleters?
20160913 16:12:16< celticminstrel> I heard it doesn't.
20160913 16:12:32< loonycyborg> well that answers it then
20160913 16:12:43< loonycyborg> since in this case a FILE* pointer is managed
20160913 16:13:11< loonycyborg> which should be released with api call and not just deleted
20160913 16:13:30< tad_> DeFender1031: lurking is good but if you think you can actually fix something in the codebase or mainline, I'd suggest jumping off the high platform into the deep end, making a PR and seeing how it goes .. some day you gotta get wet and most people will throw you a line if you start drowning
20160913 16:14:32< DeFender1031> tad_, i might do that, though I'm also not very familiar with git, which adds to my lack of confidence in jumping right in.
20160913 16:15:52< tad_> DeFender1031: SO is your friend. git is scary but the basics have good howtos and you'll do fine if you stick to them. some here know a LOT but I muddle through with just a few commands I use a lot even though there may be "better" ways.
20160913 16:19:19< DeFender1031> tad_, https://xkcd.com/1597/
20160913 16:20:08< tad_> DeFender1031: yep. that's how you start. I think we all do it that way.
20160913 16:22:55< tad_> DeFender1031: big thing I'd suggest is to try to avoid ego in your work. a PR is a "request" not a "requirement". it may take a few tries to get one accepted. start small and build up. and don't be upset if you have to make changes. Like today: I'd really prefer to get debug next_level and choose_level working but it's too much of a hack so I'm yanking it and fixing the problems that yank caused. maybe, someday, I'll come back and
20160913 16:23:11 * zookeeper yawns
20160913 16:23:21< celticminstrel> "come back and"
20160913 16:23:34< celticminstrel> (cut off)
20160913 16:23:41< DeFender1031> wb zookeeps.
20160913 16:23:45< tad_> and do it better and it'll go in. or not.
20160913 16:23:57< DeFender1031> tad_, come back and what? are you a vampire?
20160913 16:24:07< DeFender1031> ah
20160913 16:24:08< tad_> zookeeper: goback to sleep I have downsteam merge conflicts to fix before I push
20160913 16:24:12< celticminstrel> What...
20160913 16:24:40< celticminstrel> (I want to go back to sleep too. :/ )
20160913 16:24:44< DeFender1031> celticminstrel, it was a homestar runner reference. I never know where people will get those and where they won't.
20160913 16:26:24< tad_> celticminstrel: zookeeper can nap. you .. well, nose .. grindstone ..
20160913 16:26:27 * tad_ grins
20160913 16:26:47< celticminstrel> Hey, I have other things to do besides Wesnoth. Like BoE, and writing.
20160913 16:27:31< DeFender1031> Btw, something i've been wondering for a bit, is there a "head dev" of wesnoth?
20160913 16:27:39< zookeeper> nope
20160913 16:27:59< DeFender1031> so who has ultimate say on what changes make it in?
20160913 16:28:19< tad_> DeFender1031: the man who presses the big green button to merge your PR to master/HEAD
20160913 16:28:27< zookeeper> that question is too fuzzy :J
20160913 16:28:38< DeFender1031> and all "official" devs have access to that button?
20160913 16:28:46< zookeeper> yes
20160913 16:28:52< DeFender1031> cool, cool.
20160913 16:29:30< tad_> Which is another way of saying far too many have it and there are times when someone has to follow up with the red "Revert" button ..
20160913 16:29:37< DeFender1031> :/
20160913 16:29:53< celticminstrel> Hehe
20160913 16:30:06< DeFender1031> i assume then that decisions on adding "official" devs are the same? by consensus of existing devs?
20160913 16:30:10< celticminstrel> I don't think there's actually a revert button, but you get the idea.
20160913 16:30:11< zookeeper> and at least so far i don't think anyone has had that button taken away from them because it turns out they shouldn't have been trusted with it
20160913 16:30:28< celticminstrel> I think adding "official" devs right now is vultraz's decision.
20160913 16:30:53< DeFender1031> cool.
20160913 16:30:57< tad_> consensus? soemtimes. ad hoc? sometimes. it's whoever decides to push the green button 
20160913 16:31:38< tad_> And some of us (waves hand) refuse it because they think too many have it already.
20160913 16:31:47< DeFender1031> (not that i'm expecting to go from "never made a PR" to "official dev" anytime soon... just curious on what organizational structure exists for the project)
20160913 16:32:31< DeFender1031> tad_, with green buttons comes green responsibility.
20160913 16:33:12< zookeeper> there really isn't that much scrutiny to it. if someone makes a handful of non-trivial meaningful contributions and is intending on continuing to do stuff and direct push access to the repo would be convenient for them to have, then they probably get it.
20160913 16:33:26< tad_> I view it as good work-flow. Sure, I could have accepted the button when it was offered. But I think it's best to be FORCED to go through a code review.
20160913 16:34:12< zookeeper> although with github there's less reason to give people push access ASAP since the PR system is convenient enough.
20160913 16:34:52< tad_> Sure, it means someone has to do it. But look at my HttT work. It's certainly far better to adjust to zookeeper's comments and have a clean change than to push in a mistake and then have to make a correction and push it.
20160913 16:36:55< zookeeper> and yeah, even people who have push access regularly take larger changes through a PR for purposes of code review and discussion.
20160913 16:36:56< DeFender1031> tad_, i actually agree. peer-reviewing code is one of the best ways to ensure that you haven't done something massively stupid. My day job's policy is to not accept major changes without sitting down with at least one other dev and going through the code together.
20160913 16:37:35-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20160913 16:38:15-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160913 16:38:16< DeFender1031> zookeeper, so really having direct access is for people to A: approve PRs or B: make a series of single-line bug fixes without having to go through PR.
20160913 16:38:38< DeFender1031> heh, come to think of it, PR also stands for "peer-review", which is what it doubles as :P
20160913 16:38:40< tad_> DeFender1031: well, that gets me close to "kids, these days" thoughts so I'll walk away from that
20160913 16:39:50-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Ping timeout: 244 seconds]
20160913 16:40:30< celticminstrel> loonycyborg: "sys/sendfile.h" not found, what do I do? (Trying to build campaignd_asio, but currently just Wesnoth itself, not the actual campaignd.)
20160913 16:41:23< tad_> celticminstrel: look in /usr .. you probably have it and he just needs soem portability checks
20160913 16:41:42< zookeeper> DeFender1031, well, the latter is not really limited to single-line bug fixes. people still push all sorts of big changes directly, but usually that's because it's non-controversial or there just isn't much to discuss.
20160913 16:41:50< tad_> IIRC sys is the old BSD location
20160913 16:42:02< celticminstrel> I'm BSD-based.
20160913 16:42:30< DeFender1031> zookeeper, i didn't mean literally, i meant more like obvious changes rather than huge refactors or behavior changes.
20160913 16:42:32< tad_> "based" so is GNU but things changed a lot in the 90s
20160913 16:42:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160913 16:43:36< celticminstrel> ls /usr/include/sys/s* --> no sendfile.h
20160913 16:44:11< tad_> Well, that's where it is on Arch. Look elsewhere.  'find' maybe
20160913 16:44:30< celticminstrel> locate sendfile.h --> no output
20160913 16:44:37< tad_> gak
20160913 16:45:06< celticminstrel> find /usr -name sendfile.h --> no output (except permission denied on SQL directories)
20160913 16:45:08< tad_> Might check OSx docs or remember SO is your friend
20160913 16:45:38< celticminstrel> What's in sendfile.h? Maybe I can man that or something.
20160913 16:45:39 * tad_ would be amazed if OSx didn't have it at all
20160913 16:47:00< celticminstrel> Also trying to figure out how I get that list of "created xxx deleted xxx" from git...
20160913 16:47:05< tad_> sendfile.h, iirc, is memory mapped send/read of a file
20160913 16:47:27 * tad_ checks
20160913 16:47:44< celticminstrel> Oh, there's an #ifdef HAVE_SENDFILE further down the file.
20160913 16:47:51< tad_> SENDFILE(2)                                                                           Linux Programmer's Manual                                                                           SENDFILE(2)  NAME        sendfile - transfer data between file descriptors  SYNOPSIS        #include <sys/sendfile.h>         ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
20160913 16:47:58-!- JyrkiVesterinen [~JyrkiVest@87-92-56-6.bb.dnainternet.fi] has joined #wesnoth-dev
20160913 16:48:41< celticminstrel> Seems like it's in either sys/uio.h or sys.socket.h
20160913 16:49:29< tad_> gotta love unix flavors. we have so many so we have the SUS and now we have many+1 ...
20160913 16:49:37< celticminstrel>  / not .
20160913 16:49:42< celticminstrel> SUS?
20160913 16:49:50< tad_> Single Unix Standard
20160913 16:49:53-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160913 16:49:54< zookeeper> DeFender1031, for example if i add an engine feature then i'll do it through a PR since that's not really my area of expertise, but if i rewrite half of a campaign scenario or something then i'll likely just do it directly because, well, it is my area of expertise.
20160913 16:50:10-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160913 16:50:10-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160913 16:50:23< celticminstrel> I feel like there's an oversight here nonetheless - the include should also be wrapped in ifdef HAVE_SENDFILE.3
20160913 16:50:39-!- prkc [~prkc@46.166.138.147] has joined #wesnoth-dev
20160913 16:50:53< tad_> Prolly so. That's what autoconf (Scons and Cmake) are all about
20160913 16:51:40< celticminstrel> HAVE_SENDFILE is never defined in the source.
20160913 16:51:45< tad_> I remember when autoconf appeared. It was a god-send if if it was damned hard to use.
20160913 16:52:06< tad_> HAVE_SENDFILE would typically be set by autoconf as a compiler command-line option.
20160913 16:52:10< celticminstrel> So I should either define it in the project and add a dummy sys/sendfile.h somewhere, or wrap the include in an ifdef and not worry about it.
20160913 16:52:22< tad_> wrap the include
20160913 16:52:52< celticminstrel> I guess I phrased that poorly. Obviously I should wrap the include, the question is whether I should enable it for OSX.
20160913 16:52:57< tad_> bad things happen when you start doing dummy standard include files for flavors you can't use
20160913 16:53:08< tad_> hang on
20160913 16:53:20< DeFender1031> zookeeper, sensible
20160913 16:53:36< tad_> https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man2/sendfile.2.html
20160913 16:53:46< celticminstrel> I meant putting sys/sendfile.h somewhere in the repo that does nothing but include sys/uio.h and sys/socket.h
20160913 16:53:50< gfgtdf> celticminstrel: whihc file exactly includes senfile ?
20160913 16:53:53< celticminstrel> Yeah, I found that man-page already.
20160913 16:54:01< celticminstrel> gfgtdf: I'm on campaignd_asio branch.
20160913 16:55:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 16:55:54< gfgtdf> celticminstrel: ok
20160913 16:55:55< loonycyborg> celticminstrel: sendfile is linux-specific call
20160913 16:56:13< celticminstrel> So it shouldn't be used on Mac, even if it's supported?
20160913 16:56:19< loonycyborg> not sure
20160913 16:56:31< loonycyborg> if it has same signature it's worth a try
20160913 16:56:41< loonycyborg> macos could support it for easier porting
20160913 16:56:47< celticminstrel> Same function signature?
20160913 16:56:53< loonycyborg> yes
20160913 16:57:48< loonycyborg> http://man7.org/linux/man-pages/man2/sendfile.2.html
20160913 16:58:09< loonycyborg> hmm that man page seems to say that other systems could have different semantics
20160913 16:58:14< loonycyborg> so no guarantees
20160913 16:58:39< tad_> Back in the early 90s when sendfile appeared it was linux only. many others picked it up quickly
20160913 16:58:54< tad_> https://gist.github.com/justin-schroeder/d3ef404e80a7ae658a8d
20160913 16:59:03-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160913 16:59:13< celticminstrel> I guess I'll leave it alone for now.
20160913 16:59:54< tad_> There's comments from 2011 that it's broken on OSx, 2015 fixing it, sorta hard to find a clear answer
20160913 17:00:16< celticminstrel> Okay, sounds like leaving it alone is a good idea.
20160913 17:00:57< loonycyborg> celticminstrel: not such a good idea, since I didn't implement fallback for systems lacking sendfile yet
20160913 17:01:05< tad_> Found one from Jan 2015 .. says "still broken" .. so wrap the include and forget it
20160913 17:01:05< loonycyborg> in campaignd
20160913 17:02:45< celticminstrel> And wesnothd
20160913 17:02:53< loonycyborg> wesnothd isn't usingit
20160913 17:02:53< tad_> I remember sendfile was great for throughput but terrible for portability. Back then, I gave up and declared it linux-only because it was so broken on other flavors.
20160913 17:03:02< celticminstrel> I'm getting the error while building wesnothd.
20160913 17:03:18< loonycyborg> from which file?
20160913 17:03:22< celticminstrel> What's config.h?
20160913 17:03:34< celticminstrel> send_receive_wml_helpers.ipp
20160913 17:03:47< tad_> that's where autoconf shoves stuff like #define HAVE_SENDFILE 1
20160913 17:04:09< celticminstrel> So it should probably be included before sendfile.h.
20160913 17:04:19< celticminstrel> That doesn't help with it not existing for me though.
20160913 17:04:36< tad_> I'd move it above line 1 if possible.
20160913 17:04:51< celticminstrel> I'm not putting it above the intro comment. :P
20160913 17:04:55< loonycyborg> config.h is buildsystem generated
20160913 17:04:59< celticminstrel> Nor outside the include guard.
20160913 17:05:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160913 17:06:04-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160913 17:06:38< loonycyborg> celticminstrel: I mean when compiling which file it happens? .ipp shouldn't be directly compiled, it's included
20160913 17:06:46< celticminstrel> Sure, but XCode build system (and MSVC as well, presumably, though that may be less important) doesn't use it.
20160913 17:06:56< celticminstrel> Right, I should be able to tell you that.
20160913 17:07:17< celticminstrel> server.cpp includes it
20160913 17:08:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 17:08:52< loonycyborg> just guard #include <sys/sendfile.h>
20160913 17:09:25< celticminstrel> And what should I do about config.h? if !defined(__APPL__) && !defined(__MSVC) or something?
20160913 17:09:29< celticminstrel> +E
20160913 17:09:30< loonycyborg> with ifdef HAVE_SENDFILE
20160913 17:10:00< loonycyborg> Isn't it included only if you pass -DHAVE_CONFIG_H?
20160913 17:10:22< celticminstrel> No, it's included unconditionally. Should I wrap it in ifdef HAVE_CONFIG_H?
20160913 17:10:37< loonycyborg> yes
20160913 17:10:41< loonycyborg> buildsystemds pass it
20160913 17:11:02< tad_> s/^/SOME/
20160913 17:11:12< celticminstrel> Yay, link errors. Presumably because it didn't compile server_base.cpp.
20160913 17:13:25< tad_> So you do all the work and get it working on all the BSD-ish systems, then fight with Windows, and someone comes along and asks about porting to SysV support. Oh, the painful memories.
20160913 17:15:23-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160913 17:15:46< celticminstrel> Except, apparently, Darwin.
20160913 17:18:07< celticminstrel> Now I'm building campaignd and getting "use of undeclared identifier async_send_file"... guessing that's something wrapped in ifdef HAVE_SENDFILE...
20160913 17:20:57< celticminstrel> I could just stop here and wait for you to implement fallbacks for lack of sendfile, I guess.
20160913 17:21:22< celticminstrel> Though I'd like to make sure it can link...
20160913 17:22:44< tad_> maybe put in a stub with a throw(not_implemented_exception) and test until it throws?
20160913 17:22:55-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160913 17:22:56< celticminstrel> Hmm, that could work.
20160913 17:23:19-!- atarocch [~atarocch@HSI-KBW-46-223-95-173.hsi.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20160913 17:23:27< celticminstrel> Incidentally, my sendfile is not compatible with the one loonycyborg used (his needs two additional arguments).
20160913 17:25:13< tad_> I'm really not liking all the thinking I'm having to do to handle yanking that commit. The expedient thing to do might be to put it back in and remove the [kill] junk and fix the li'sar mess.  **sighs**
20160913 17:26:44< celticminstrel> Undefined symbol: _default_campaignd_port
20160913 17:30:28-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20160913 17:30:58< mordante> servus
20160913 17:41:30< celticminstrel> loonycyborg: Does the campaign server use the LOCALEDIR and/or FIFODIR defines?
20160913 17:41:54< celticminstrel> I guess it probably would use LOCALEDIR at least.
20160913 17:43:20 * celticminstrel asking because I made the campaignd target by duplicating the wesnothd target and modifying it, rather than starting from scratch.
20160913 17:48:10-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160913 17:53:25-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160913 17:56:50-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160913 18:00:02-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20160913 18:00:02-!- wedge010 is now known as wedge009
20160913 18:16:50< loonycyborg> celticminstrel: FIFODIR is used by campaignd
20160913 18:17:04< loonycyborg> LOCALEDIR is used only by clientside afaik
20160913 18:17:13< celticminstrel> Oh.
20160913 18:17:30< celticminstrel> So FIFODIR should preumable at least be set to a different value than for wesnothd.
20160913 18:18:04< celticminstrel> ^presumably
20160913 18:18:15< celticminstrel> I suppose it doesn't really matter what exactly.
20160913 18:20:29< irker231> wesnoth: Celtic Minstrel wesnoth:campaignd_asio 404c6ca75414 / / (2 files in 2 dirs): Fix XCode wesnothd build https://github.com/wesnoth/wesnoth/commit/404c6ca754140ca4a8979e0a204d47dad38151f3
20160913 18:20:31< irker231> wesnoth: Celtic Minstrel wesnoth:campaignd_asio d0b8b471c5c7 / / (2 files in 2 dirs): Add campaignd target to XCode project https://github.com/wesnoth/wesnoth/commit/d0b8b471c5c754c8a972aa712d3ad0bd5469387e
20160913 18:26:33< irker231> wesnoth: Jyrki Vesterinen wesnoth:master c4992dcd3819 / utils/travis/mp_test_executor-gui2.sh: viesti.txt https://github.com/wesnoth/wesnoth/commit/c4992dcd3819d5966b2d79a2e64c00c17ba64531
20160913 18:26:35< irker231> wesnoth: Jyrki Vesterinen wesnoth:master 5e930ea5fb7b / src/gui/ (5 files in 4 dirs): Fix GUI2 multiplayer tests getting stuck https://github.com/wesnoth/wesnoth/commit/5e930ea5fb7bc6b67143d34819f5455da0ec3a8d
20160913 18:26:52< JyrkiVesterinen> The tests are now passing reliably on my system. :)
20160913 18:27:01< celticminstrel> \o/
20160913 18:27:29< JyrkiVesterinen> I'll need to check if there is a sensible way to get Travis to run them. The tests are assuming that the GUI2 lobby is enabled.
20160913 18:27:50< JyrkiVesterinen> I wonder if it would be easy enough to turn the GUI2 lobby on programmatically.
20160913 18:28:19< celticminstrel> Should be easy. I think vultraz intends to make it the default in the next release, though.
20160913 18:29:03< JyrkiVesterinen> (Whoops at the first commit message. I accidentally passed -m to Git instead of -F. :( )
20160913 18:29:11-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160913 18:29:37< JyrkiVesterinen> (Git commit command, that is.)
20160913 18:30:33< celmin> -F?
20160913 18:31:12< JyrkiVesterinen> Git commit -F reads the commit message from the named file.
20160913 18:32:45< celticminstrel> Hmm, seeing your commit, I think I've benn setting allow_pugins_skip too late as well.
20160913 18:32:46< celticminstrel> \
20160913 18:32:50< celticminstrel> Gah
20160913 18:34:33< gfgtdf> loonycyborg: you know what tehbranch BRANCH_vendor_gettext is for'? has it still any value ?
20160913 18:34:36< celmin> ^been
20160913 18:35:17< loonycyborg> gfgtdf: I was wondering that myself
20160913 18:35:33< loonycyborg> so no idea
20160913 18:35:39< celmin> I can guess from the name what it's for.
20160913 18:35:54< celmin> "Refactor Wesnoth to use the vendor's gettext implementation instead of Boost, if available"
20160913 18:36:10< gfgtdf> Ivanovic: you know what tehbranch BRANCH_vendor_gettext is for'? has it still any value ? Can it be removed?
20160913 18:36:12< celmin> I think Wesnoth no longer supports using non-Boost gettext, though.
20160913 18:36:42< celmin> Then again, the point of it might've been adding support, I dunno.
20160913 18:37:49< gfgtdf> any opinion on remving all merged branche? that is all branches with no commits ahead of master?
20160913 18:37:52< celmin> So vultraz, Jyrki: Now that plugins work with the GUI2 lobby, how about load-testing it?
20160913 18:38:23< celmin> gfgtdf: If it's already merged then we don't need it anymore. Note that this excludes boost_trimming.
20160913 18:38:46< gfgtdf> celmin: you you still working on boost_trimming ?
20160913 18:38:55< irker231> wesnoth: Jyrki Vesterinen wesnoth:master e93ae16cfdb9 / src/editor/palette/location_palette.cpp: location_palette_item: Fix signed to unsigned conversion compiler warning https://github.com/wesnoth/wesnoth/commit/e93ae16cfdb96f7fd2adfc82783fb7ed682c65ac
20160913 18:39:14< celmin> No, but there's one commit outstanding due to poor GCC 4.something regex support.
20160913 18:39:27< JyrkiVesterinen> celmin: What exactly are you asking about load-testing?
20160913 18:39:43< gfgtdf> celmin: can we remove sdl2 branch ?
20160913 18:39:54< celmin> gfgtdf: Probably?
20160913 18:41:08< celmin> JyrkiVesterinen: From what I've heard, one of the big reasons for the GUI2 lobby not being enable by default yet was that it performed poorly when there are many users online and/or many games active.
20160913 18:42:00< celmin> Since vultraz want to enable it by default now, we need to somehow attempt to show that it performs decently in such conditions.
20160913 18:42:44< JyrkiVesterinen> Hmm... I don't really know how the GUI2 lobby can be load-tested.
20160913 18:43:48< JyrkiVesterinen> If there is a high number of games/players in the 1.13 server, then I guess we could just connect 1.13.5+dev to that server.
20160913 18:46:04< gfgtdf> Aginor: what teh state of the https://github.com/wesnoth/wesnoth/commits/renderpath_redo branch ? is it wtill bein worked on or can it be deleted ?
20160913 18:48:16< gfgtdf> celmin: i think it'd be nice if we coudl use the 'plugin' thing to make some stresstest for the mp server.
20160913 18:49:04< celmin> JyrkiVesterinen: My thought was to use the host.lua script to create 100 or so games, then log in normally and see how it goes.
20160913 18:49:06< gfgtdf> celmin: we coudl maybe use teh 'cores' feture to make a minimalisic 'core' to decrease wesnoth memeory useage and to be able to run more wesnoth clients on the same comuter.
20160913 18:49:21< celmin> Though using a custom plugin script would also be in the realm of possibility.
20160913 18:50:02< celmin> gfgtdf: I doubt that's the actual issue here.
20160913 18:50:33< celmin> Though if it were, I'd think surrounding the campaigns include with #ifndef MULTIPLAYER would solve it (though that'd also block out LoW).
20160913 18:50:57< gfgtdf> celmin: i dsont think te campaigns take much space.
20160913 18:51:16< gfgtdf> celmin: they contents is usualyl already included in theor own campaign define ifdef
20160913 18:51:19< gfgtdf> their*
20160913 18:51:26< celmin> Then what part are you proposing to omit in a "minimalistic core"?
20160913 18:51:51< gfgtdf> celmin: maybe only 2 units and 2 mp maps or something.
20160913 18:52:18< celmin> ...
20160913 18:54:00< JyrkiVesterinen> Hmm, indeed, it would be possible to simulate some load with a custom plugin.
20160913 18:54:42< celmin> Note that it's the client-side lobby being tested, not the server, so I think you'd have to log in at least one client through the GUI.
20160913 18:56:00< gfgtdf> celmin: but we want to test the server aswell, sicne we didnt test it with > 3 games after it was ported to asio.
20160913 18:56:11< celmin> Sure, I guess...
20160913 18:56:16< JyrkiVesterinen> Right... dozens of clients with --nogui just generating traffic, and one client with the GUI shown to test if the GUI remains reasonably responsive.
20160913 18:57:22< JyrkiVesterinen> I can check next week or so if such a load test would be feasible.
20160913 18:57:46< JyrkiVesterinen> (I can easily imagine that the test eats too much memory or network sockets or something.)
20160913 18:59:19< celmin> Maybe several devs could collaborate on it?
20160913 19:10:56-!- travis-ci [~travis-ci@ec2-54-198-188-174.compute-1.amazonaws.com] has joined #wesnoth-dev
20160913 19:10:57< travis-ci> wesnoth/wesnoth#10900 (campaignd_asio - d0b8b47 : Celtic Minstrel): The build has errored.
20160913 19:10:57< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159673558
20160913 19:10:57-!- travis-ci [~travis-ci@ec2-54-198-188-174.compute-1.amazonaws.com] has left #wesnoth-dev []
20160913 19:13:54< gfgtdf> mordante: what is that 'mordante_terrain' branch? can it be deleted?
20160913 19:15:03< mordante> gfgtdf, I thought it already had been deleted :-/
20160913 19:15:27< mordante> gfgtdf, it is the change from the terrain system from a single letter to the multiple letters
20160913 19:15:53< gfgtdf> mordante: and what is the 'terrain-layer' branch ?
20160913 19:16:00< mordante> so it was possible to have more than about 60ish branch
20160913 19:16:09< mordante> that is the one mog made isn't it?
20160913 19:22:03-!- lobby [~wesnoth@baldras.wesnoth.org] has joined #wesnoth-dev
20160913 19:22:03-!- Topic for #wesnoth-dev: 1.13.6 planned for late September | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160913 19:22:03-!- Topic set by vultraz [~chatzilla@wesnoth/developer/vultraz] [Sun Sep 11 23:24:46 2016]
20160913 19:22:03[Users #wesnoth-dev]
20160913 19:22:03[ 43UAAAAAH   ] [ celmin       ] [ Guest458   ] [ mattsc   ] [ Ravana_    ] [ vultraz  ] 
20160913 19:22:03[ _laco       ] [ clavi        ] [ Guest92877 ] [ midzer   ] [ Rhonda     ] [ wedge009 ] 
20160913 19:22:03[ abruanese   ] [ DeFender1031 ] [ iwaim__    ] [ mordante ] [ shikadibot ] [ Yaiyan   ] 
20160913 19:22:03[ aeth        ] [ EliDupree    ] [ Jetrel     ] [ new_one  ] [ ShikadiLord] [ zookeeper] 
20160913 19:22:03[ Aginor      ] [ Elsi         ] [ Jetrel_bot ] [ nurupo   ] [ Sirp_      ] 
20160913 19:22:03[ aidanhs     ] [ Elvish_Hunter] [ kidneb     ] [ oldlaptop] [ stikonas   ] 
20160913 19:22:03[ ancestral   ] [ enchi        ] [ knotwork   ] [ Polsaker ] [ TheJJ      ] 
20160913 19:22:03[ APic        ] [ esr          ] [ lobby      ] [ prkc     ] [ timotei_   ] 
20160913 19:22:03[ bumbadadabum] [ Greg-Boggs   ] [ loonycyborg] [ pydsigner] [ vincent_c  ] 
20160913 19:22:03-!- Irssi: #wesnoth-dev: Total of 49 nicks [0 ops, 0 halfops, 0 voices, 49 normal]
20160913 19:22:09-!- Channel #wesnoth-dev created Tue Jan 27 05:28:41 2009
20160913 19:22:16-!- irker231 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160913 19:22:16-!- TC01 [~quassel@128.220.251.37] has joined #wesnoth-dev
20160913 19:22:16-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20160913 19:22:16-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20160913 19:22:36-!- JyrkiVesterinen [~JyrkiVest@87-92-56-6.bb.dnainternet.fi] has joined #wesnoth-dev
20160913 19:22:36-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20160913 19:22:36-!- AI0867 [~ai@wesnoth/developer/ai0867] has joined #wesnoth-dev
20160913 19:22:52-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev
20160913 19:22:52-!- miniplane [~min@meta23.net] has joined #wesnoth-dev
20160913 19:23:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160913 19:23:09-!- Irssi: Join to #wesnoth-dev was synced in 74 secs
20160913 19:23:16-!- Greywhind [~Greywhind@c-71-232-29-126.hsd1.ma.comcast.net] has joined #wesnoth-dev
20160913 19:23:16-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160913 19:23:16-!- Appleman1234 [~Appleman1@KD119104112233.au-net.ne.jp] has joined #wesnoth-dev
20160913 19:23:20-!- higgins [~higgins@68.ip-149-56-14.net] has joined #wesnoth-dev
20160913 19:23:21-!- Ivanovic [~ivanovic@p579FB681.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160913 19:23:21-!- atarocch [~atarocch@HSI-KBW-46-223-95-173.hsi.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20160913 19:23:21-!- gfgtdf [~chatzilla@x4e363432.dyn.telefonica.de] has joined #wesnoth-dev
20160913 19:23:21-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20160913 19:23:21-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160913 19:23:21-!- DDR [~david@ec2.happyspork.com] has joined #wesnoth-dev
20160913 19:23:21-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20160913 19:23:21-!- Soliton [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev
20160913 19:23:38-!- 43UAAAAAH [add94167@gateway/web/freenode/session] has left #wesnoth-dev []
20160913 19:23:47-!- tad_ [add94167@gateway/web/freenode/session] has joined #wesnoth-dev
20160913 19:24:05-!- tad_ [add94167@gateway/web/freenode/session] has quit [Changing host]
20160913 19:24:05-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160913 19:25:24< mordante> gfgtdf, the tarrain-layer was the one of mog wasn't it?
20160913 19:25:38-!- matthiaskrgr [matthiaskr@gateway/shell/panicbnc/x-arexxphpihyggosi] has joined #wesnoth-dev
20160913 19:25:43< gfgtdf> mordante: ''mog' ?
20160913 19:26:02-!- matthiaskrgr is now known as Guest28768
20160913 19:26:13< mordante> gfgtdf, yes, he mainly was a terrain artist
20160913 19:26:32-!- Guest28768 [matthiaskr@gateway/shell/panicbnc/x-arexxphpihyggosi] has quit [Changing host]
20160913 19:26:32-!- Guest28768 [matthiaskr@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20160913 19:26:32-!- Guest28768 [matthiaskr@unaffiliated/matthiaskrgr] has quit [Changing host]
20160913 19:26:32-!- Guest28768 [matthiaskr@gateway/shell/panicbnc/x-arexxphpihyggosi] has joined #wesnoth-dev
20160913 19:26:52-!- Guest28768 is now known as matthiaskrgr_
20160913 19:26:53< gfgtdf> mordante: the github commit says ' Moritz Göbelbecker 
20160913 19:27:06< mordante> that's him
20160913 19:27:22< mordante> mog is the name he used on the forum
20160913 19:27:24-!- Appleman1234 [~Appleman1@KD119104112233.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20160913 19:28:04< mordante> that branch can also be removed
20160913 19:28:19< irker231> wesnoth: Celtic Minstrel wesnoth:master a3be5244ffeb / src/gui/dialogs/ (lobby/lobby.cpp multiplayer/mp_create_game.cpp title_screen.cpp): Clear allow_plugin_skip earlier in titlescreen and MP lobby / create https://github.com/wesnoth/wesnoth/commit/a3be5244ffeb312c022dc41abba1d0a1ac266b33
20160913 19:28:59< gfgtdf> mordante: done
20160913 19:29:43< gfgtdf> mordante: you know about that 'BRANCH_vendor_gettext' granch ? it contains oynl one file that is 'po/Makefile.in.in'
20160913 19:30:05< gfgtdf> mordante: banch *
20160913 19:30:18< mordante> get's closer ;-)
20160913 19:30:38< mordante> I have a feeling of deja vu, I thought all these ancient branches had been deleted a long time ago
20160913 19:30:46< mordante> does Xan also still exist?
20160913 19:30:46< celmin> vultraz: Where are you.
20160913 19:31:23< gfgtdf> mordante: no i deleted that already since it had oviously no non-merged commits.
20160913 19:31:39< gfgtdf> mordante: i'll take that as BRANCH_vendor_gettext cna be deleted
20160913 19:31:42< mordante> I can't exactly recall what was with the gettext branch, but I'm quite sure it has been deleted in the past
20160913 19:31:46< tad_> What? old, abandoned branches are being cleaned up?
20160913 19:32:01< mordante> gfgtdf, you just deleted Xan?
20160913 19:32:47< gfgtdf> mordante: hmmyes i said 0 commits haead of mastr
20160913 19:32:52< gfgtdf> ahead*
20160913 19:33:28< mordante> gfgtdf, yes no problem but I feel some ancient branches have resurfaced
20160913 19:34:53< tad_> zookeeper: You up from your nap, yet? Quick question if you are.
20160913 19:35:09< zookeeper> tad_, i never went back
20160913 19:37:02< tad_> zookeeper: I tried just yanking that commit and the merge conflicts for the other PRs was too much work. So, I removed all the [kill][unit] stuff and cleaned up Li'sar in S19. That leaves the hero store/restore stuff and the changes to what happens when on victory and avoided the conflicts. Do you have issues with those?
20160913 19:39:51< zookeeper> but there wasn't anything special WRT li'sar in S19?
20160913 19:40:56< tad_> Maybe I remembered wrong scene. Where she leaves side 2 and joins side 1 .. that store/variable/unstore stuff to preserve her stats instead of replace her if you ;cl ..
20160913 19:41:31< tad_> I just left it as [modify_unit] and it works fine
20160913 19:42:05< zookeeper> oh S16
20160913 19:42:19< tad_> Ah, right. I just looked.
20160913 19:43:23< zookeeper> hmh
20160913 19:43:37< tad_> So there was a [modify_unit] and it worked fine so I removed the stores and variable work and she's fine for normal play. For ;cl she might dup.
20160913 19:43:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160913 19:44:42< zookeeper> tad_, doesn't your change mean that she won't have the loyal trait?
20160913 19:45:12< vultraz> celmin: hm?
20160913 19:45:13< tad_> I set her as a Hero but I'll check, Might need to add the trait.
20160913 19:45:42-!- Lohengramm [sid1929@gateway/web/irccloud.com/x-qjmyugevqzzhjcsg] has joined #wesnoth-dev
20160913 19:46:18< zookeeper> well i don't know if MAKE_HERO does that
20160913 19:46:40< tad_> It does not. OK. I'll add it.
20160913 19:47:36< vultraz> mordante: you were saying the other day there possibly is a label size limit?
20160913 19:48:30< zookeeper> tad_, i'm not sure what the remaining purpose of that change is though
20160913 19:49:17< tad_> Which change? Li'sar specifically or what I left in place in general?
20160913 19:49:21< zookeeper> li'sar
20160913 19:49:28< zookeeper> S16, victory event
20160913 19:50:27< tad_> She is on side 2 and needs to change to side 1. [modify_unit] does it. I just need to add {TRAIT_LOYAL} and she's golden .. side 1, hero, healed and ready to rumble in S17
20160913 19:50:33< celmin> vultraz: What scroll speed do you want as the default?
20160913 19:51:15< zookeeper> tad_, yeah of course, but the existing code already did that
20160913 19:51:23< vultraz> celmin: around what I have in the credits screen now
20160913 19:51:35< mordante> vultraz, there was a limit in the size of a surface in SDL
20160913 19:51:57< vultraz> hmmm
20160913 19:51:59< mordante> the size was a short
20160913 19:52:00< vultraz> was?
20160913 19:52:10< tad_> with a bunch of stores and variable work most of which [modify_unit] does much better. If I can't quickly add loyal, I'll fall back to the original.
20160913 19:52:19< mordante> but I think it changed to int or int16_t in SDL2
20160913 19:52:20< celmin> vultraz: I want numbers here.
20160913 19:52:37< vultraz> celmin: it's 1px every 10 ms.
20160913 19:52:42< mordante> but creating such a large surface may cause out of memory issues
20160913 19:53:05< celmin> So… 10px per second?
20160913 19:53:22< zookeeper> tad_, your code for is more complicated and longer, so i just don't see what the benefit is
20160913 19:53:47< tad_> Oh. all that is gone. it's just a [modify_unit]
20160913 19:53:48< zookeeper> the original code does... apparently everything it needs to do, and is super simple
20160913 19:53:54< zookeeper> oh, right
20160913 19:54:00< celmin> vultraz: ^
20160913 19:54:17< vultraz> mordante: the odd thing is I get no warnings that the surface is too big.. and if i print the contents via .label() to console it's all there... just doesn't display :/ still, you could be right.. I'll need to come up with another solution.
20160913 19:54:25< vultraz> celmin: uh ... yes
20160913 19:54:26< zookeeper> tad_, well in that case it's fine. if it works, that is :J
20160913 19:55:32< celmin> vultraz: So, is jumping in 10px increments acceptable?
20160913 19:55:43< celmin> Or do I need to limit it to eg 5px increments as much as possible?
20160913 19:55:52< vultraz> hm
20160913 19:56:02< vultraz> whatever seems smoothest
20160913 19:56:15< zookeeper> what's that about?
20160913 19:56:23< tad_> I'm checking my change to be sure she's good. I'll cross-check against current master to be sure I didn't miss anything.
20160913 19:56:29< celmin> Where was about.cpp again?
20160913 19:56:45< vultraz> src/
20160913 19:57:03< celmin> Not seeing it there in the XCode project...
20160913 19:57:11< celmin> Ohh.
20160913 19:57:18< celmin> It's above actions/addons/ai
20160913 19:58:58< tad_> zookeeper: Looks good. Don't need to save and use variables. [modify_unit] does it without [store-kill][unit]variable= .. clean and readable.
20160913 19:59:19< zookeeper> okay then
20160913 20:00:04< celmin> mordante: Can you explain anything about [matrix]?
20160913 20:00:11< celmin> Like, what it is and stuff.
20160913 20:00:29< tad_> So a few cleanups, a final run-through in case I broke something and I'll push .. or I can clean up and push just general improvements now and you can give final review while I check no breakage elsewhere
20160913 20:01:24< zookeeper> whatever you prefer
20160913 20:02:40< tad_> zookeeper: I will go with my normal process (by hand .. no more Bash script errors for me, ty) and push when I'm done.
20160913 20:05:13< mordante> vultraz, it the code in master or locally
20160913 20:05:15< mordante> ?
20160913 20:05:29< vultraz> mordante: which code?
20160913 20:05:40< vultraz> the end credits code?
20160913 20:05:41< vultraz> it's in master
20160913 20:05:45< celmin> If I recall correctly, it's in master, but you need to uncomment about.cpp line 234.
20160913 20:05:59< vultraz> ^
20160913 20:06:06< celmin> Note that I'm currently doing stuff on the end credits timer thing though.
20160913 20:06:08< vultraz> right now, it displays
20160913 20:06:37< vultraz> but if you increase the size of the widget (ie, make the definition default_large), or add more newlines in there, it won't display.
20160913 20:07:24< mordante> vultraz, I'll update my repro and will have a look, but I'm about to leave so no results today
20160913 20:10:22< mordante> celmin, can't recall exactly also not its state, will have to look at it another time
20160913 20:10:42 * celmin assumes that's in response to [matrix] query.
20160913 20:12:14-!- JyrkiVesterinen [~JyrkiVest@87-92-56-6.bb.dnainternet.fi] has quit [Quit: .]
20160913 20:12:48< mordante> celmin, yes
20160913 20:14:33< vultraz> celmin: so what are you doing exactly?
20160913 20:18:34< celmin> Variably speed
20160913 20:18:39< celmin> ^e not y
20160913 20:18:58< celmin> Like I promised… was it two days ago now?
20160913 20:19:34-!- Guest458 is now known as elias
20160913 20:19:35< vultraz> but how are you implementing it
20160913 20:19:46< celmin> That's what I'm trying to figure out.
20160913 20:19:54-!- elias [~allefant@allefant.com] has quit [Changing host]
20160913 20:19:54-!- elias [~allefant@allegro/developer/allefant] has joined #wesnoth-dev
20160913 20:20:05< celmin> It'll definitely involve SDL_GetTicks though.
20160913 20:20:29< vultraz> I hope you're wiring better autoscroll functionality into the scrollbars
20160913 20:20:44< celmin> No?
20160913 20:20:57< vultraz> what, this is entirely dialog-local? :/
20160913 20:21:02< celmin> You already have these stubs in the end credits dialog after all.
20160913 20:21:27< celmin> Do we even need auto-scroll anywhere else?
20160913 20:22:44< vultraz> no
20160913 20:23:11< tad_> Long storyboard messages?
20160913 20:23:18< celmin> Hmm, maybe.
20160913 20:23:37< tad_> Seems to me 1.12.6 scrolls them .. but I'd have to check
20160913 20:23:40< celmin> Though they'd have to get really long, and they could easily be split into two parts.
20160913 20:23:47< celmin> But still, maybe.
20160913 20:24:04< celmin> Mind you, I don't think variable scroll speed is likely needed there...
20160913 20:24:26< tad_> Actually, I think it would be very nice to merge them together as much as possible, autoscroll them, then end with a scrolbar so I can roll back and re-read without reloading
20160913 20:24:45< celmin> You can always use the "previous" button?
20160913 20:24:46< vultraz> variable scroll speed is not, though
20160913 20:24:47< tad_> But that's a big change
20160913 20:25:11< vultraz> and i guess we can't get truly smooth scrolling as long as we use surfaces
20160913 20:25:43< celmin> You can't get truly smooth scrolling as long as you use integers.
20160913 20:25:59< celmin> Truly smooth scrolling at any speed would require real numbers.
20160913 20:26:06< celmin> But honestly, that's overkill.
20160913 20:26:10< tad_> smooth is jumpy under load anyway. you should see it on my screen when I get low on memory or something is running in the background
20160913 20:26:22< vultraz> why can't we do that, then
20160913 20:26:28< celmin> But honestly, that's overkill.
20160913 20:26:31< celmin> ^
20160913 20:26:59< celmin> Anyway, we're working in pixels, not on the GPU, so that's the actual answer to your question.
20160913 20:27:51< celmin> Even so, I'm pretty sure a step of 5-10 pixels will still appear smooth at normal speeds.
20160913 20:28:31< celmin> I think maybe smoothness is really more about the timing.
20160913 20:28:32-!- Appleman1234 [~Appleman1@KD119104112233.au-net.ne.jp] has joined #wesnoth-dev
20160913 20:29:58< tad_> It's all about FPS
20160913 20:30:53< celmin> vultraz: What should be the minimum and maximum scroll speeds?
20160913 20:31:03< mordante> I'm off bye
20160913 20:31:05-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has quit [Quit: Leaving]
20160913 20:31:08< celmin> Is 1 px/s slow enough for a minimum?
20160913 20:31:33 * celmin suspects not.
20160913 20:31:36< vultraz> celmin: half of current min, max 2x
20160913 20:31:48< celmin> I don't know what current min and max are.
20160913 20:31:55< celmin> Your numbers look totally arbitrary to me.
20160913 20:32:24< celmin> When you say 2x, do you mean 2x normal or 2x whatever you had as the max before?
20160913 20:32:47< vultraz> blah
20160913 20:32:52< vultraz> let me rephrase
20160913 20:33:09< vultraz> my logic is off
20160913 20:33:26< celmin> I just need numbers in px/s.
20160913 20:34:05< vultraz> no faster than 20px/s and no slower than 5 px/s
20160913 20:34:24< celmin> Or px/ms would work too.
20160913 20:34:31< celmin> Hmm.
20160913 20:35:22< celmin> 1px / 10 ms ≠ 10 px / 1 s ...
20160913 20:35:26< celmin> …right?
20160913 20:35:44 * celmin seems to have a math error here.
20160913 20:36:16< celmin> vultraz: Okay, so are you saying there should only be three allowed speeds?
20160913 20:36:39< vultraz> wait a second, it's 1000 ms per second not 100 >_>
20160913 20:36:43 * vultraz just woke up
20160913 20:36:54< celmin> I suppose I could stick with your increment thing...
20160913 20:37:08< vultraz> the increment thing is just copied from the old dialog
20160913 20:37:23< celmin> I was thinking of making it up halve it and down double it.
20160913 20:38:04< celmin> 1px / 10 ms = 100 px/s ?
20160913 20:38:57< vultraz> one would think
20160913 20:38:59< zookeeper> what scrolling is this about?
20160913 20:39:02< vultraz> but somehow that doesn't sound right
20160913 20:39:05< celmin> zookeeper: Credits.
20160913 20:39:16< zookeeper> okay
20160913 20:39:26< celmin> vultraz: 100 px/s doesn't necessarily mean scrolling in increments of 100 px.
20160913 20:39:34< celmin> Just to make that quite clear.
20160913 20:39:38< vultraz> yes
20160913 20:39:55< vultraz> i just meant it seemed a little too fast for what i saw
20160913 20:40:10< vultraz> but i guess my scree is only 900 px tall
20160913 20:40:14< vultraz> screen
20160913 20:40:19< vultraz> so yeah, that seems right
20160913 20:40:52< vultraz> which would make the min/max 50/200
20160913 20:41:10< celmin> I could go as low as 25, I guess.
20160913 20:41:19< celmin> Any further and I'd have to use a float.
20160913 20:41:38< vultraz> zookeeper: any objections to merging the merfolk castle PR?
20160913 20:41:51 * tad_ smiles. To me the only thing which matters when I get there is waiting FOREVER to "The End" to disappear. Then the question is how quickly I can smash Esc.
20160913 20:42:08< celmin> tad_: Huh?
20160913 20:42:20< vultraz> he never looks at the credits :P
20160913 20:42:27< tad_> When I win a campaign and .. yeah 
20160913 20:42:44< celmin> Why does it take forever for "The End" to appear?
20160913 20:42:45< tad_> Bet I'm not alone in that
20160913 20:42:49 * vultraz considers being evil and disabling ESC closure in the credits >: D
20160913 20:42:55< celmin> No.
20160913 20:42:57< tad_> Because it's like 5 second and does not honor Esc
20160913 20:43:02< vultraz> celmin: obviously
20160913 20:43:06< vultraz> I'm joking :|
20160913 20:43:10< celmin> Good.
20160913 20:43:12< zookeeper> vultraz, probably not, i was gonna look at it tomorrow though
20160913 20:43:23< vultraz> alright ill let you look
20160913 20:43:27< tad_> Set it to 1 px/10s and disable Esc ...
20160913 20:43:36< celmin> Gasp.
20160913 20:43:53< celmin> If you did that I'd just kill Wesnoth and restart it.
20160913 20:44:28< celmin> Do campaign credits come before or after main game credits? I can't remember.
20160913 20:44:37< vultraz> before
20160913 20:44:41< celmin> Oh good.
20160913 20:45:04< celmin> BTW I think it might be better for the end credits dialog to parse the WML, rather than that vector of strings...
20160913 20:45:44< vultraz> obviously
20160913 20:45:56< vultraz> the handling needs to be rewritten
20160913 20:45:59< vultraz> it's shitty
20160913 20:45:59 * zookeeper wonders what's the easiest and cleanest way to download all the added files in a PR
20160913 20:46:25< tad_> Zip
20160913 20:46:31< celmin> zookeeper: git fetch origin refs/pull/###/HEAD ; git merge FETCH_HEAD
20160913 20:46:34< celmin> Something like that.
20160913 20:46:52< celmin> Instead of merge you could git checkout -b new_branch FETCH_HEAD
20160913 20:47:21< celmin> What tad_ said might work, I dunno,
20160913 20:47:38-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160913 20:47:43< celmin> But probably not...
20160913 20:48:03< zookeeper> "Zip" might work?
20160913 20:48:10< zookeeper> like wth
20160913 20:48:24< celmin> I know github has options for downloading zips, but it might just be "whole repository" zips.
20160913 20:48:30< zookeeper> indeed
20160913 20:48:38< celmin> So fetch is probably best then.
20160913 20:50:03< irker231> wesnoth: Charles Dang wesnoth:surface_cleanup 86d187e106b2 / / (48 files in 14 dirs): Convert remaining SDL1.2 keywords to their SDL2 counterparts and dropped compat  https://github.com/wesnoth/wesnoth/commit/86d187e106b2dba5c27029ed7001623f54042748
20160913 20:50:21< celmin> "keywords"
20160913 20:50:25-!- ShikadiLord is now known as shadowm
20160913 20:50:57< celmin> Please call them constants, not keywords.
20160913 20:51:05< celmin> What? Why'd they rename the meta key?
20160913 20:51:39< celmin> I guess some of them aren't constants. Still, they're not keywords either.
20160913 20:53:06< vultraz> oh well
20160913 20:53:12< shadowm> Keywords are compiler-defined syntax elements like `for`, `if`, `do`, `while`, `class`, `struct`, `union`, `enum`, `public`, `private`, `protected`, etc.
20160913 20:53:20< celmin> ^
20160913 20:53:34< vultraz> Then what would you call those.
20160913 20:53:45< vultraz> defines?
20160913 20:53:46< shadowm> Their main defining attribute is that they cannot be used as identifiers.
20160913 20:54:00< celmin> vultraz: Your change to video.hpp in that commit is absolutely hilarious. :P
20160913 20:54:41< vultraz> oh deer
20160913 20:54:54< celmin> It's a wrapper for itself!
20160913 20:55:19< celmin> You could call them defines, sure. Since that's what they are.
20160913 20:55:23 * tad_ visualizes vultraz as deer in the headlights.
20160913 20:55:28< celmin> Haha
20160913 20:56:18< shadowm> That sounds like him when encountering syntax he's never used before.
20160913 20:57:06< vultraz> no, then I'm
20160913 20:57:09< vultraz> *flails*
20160913 20:57:30< celticminstrel> Time to see if this works.
20160913 20:57:48< celticminstrel> Looks like the answer is... no. /
20160913 20:57:51< celticminstrel> :/
20160913 20:58:04< celticminstrel> It's just jumping straight to the bottom.
20160913 20:58:09< celticminstrel> Debugging time!
20160913 20:58:15< celticminstrel> Oh also...
20160913 20:59:50< celticminstrel> I wonder if there's a way to prevent the scroll label from responding to the mouse wheel.
20160913 21:00:37< gfgtdf> celmin: why woudl you want that ?
20160913 21:00:56< celticminstrel> gfgtdf: For the end credits.
20160913 21:01:08< vultraz> use my unimplemented always_hidden mode :P
20160913 21:01:10< celticminstrel> The GUI1 version isn't scrollable, so I figure the GUI2 version should preserve that.
20160913 21:01:12< vultraz> that's what happened
20160913 21:01:28< celticminstrel> vultraz: That's not exactly desirable though, eg for menus.
20160913 21:02:09< vultraz> youll need a different mode for that
20160913 21:02:15< gfgtdf> celmin: when i watched the end credit i was rather annoyed that it is not scrollable.
20160913 21:02:25< celticminstrel> vultraz: That seems a bit much, honestly.
20160913 21:02:53< celticminstrel> gfgtdf: I see.
20160913 21:06:16< irker231> wesnoth: Ignacio R. Morelle wesnoth:master 85d277dd45da / src/desktop/version.cpp: Drop newly superfluous include https://github.com/wesnoth/wesnoth/commit/85d277dd45dabf529053589be80e0f13d3c7657b
20160913 21:06:22< celticminstrel> I think I already discovered my error, too. We'll soon see, though.
20160913 21:06:31< shadowm> I always find it a bit jarring that Wesnoth's cursor is about 1.5x larger than my system cursor.
20160913 21:06:44< shadowm> Wesnoth's new cursor.
20160913 21:07:05< celticminstrel> I've somehow gotten an impression that games tend to have larger cursors.
20160913 21:07:16-!- mjs-de [~mjs-de@x4e30284e.dyn.telefonica.de] has joined #wesnoth-dev
20160913 21:07:43< shadowm> Are they always standard-shaped, though?
20160913 21:07:49< gfgtdf> i loonycyborg we removed the scoped_resource.hpp file ?
20160913 21:08:06< gfgtdf> i thought*
20160913 21:08:07< loonycyborg> no
20160913 21:08:29< celticminstrel> I think some games have arrows. if that's what you mean. Though probably not quite the same as a standard arrow.
20160913 21:09:09< shadowm> I mean whether they usually have as much solid space as the system cursor shape (which is what Wesnoth's is evidently based on).
20160913 21:10:10< celticminstrel> I'm not sure, but I think there have been some that do.
20160913 21:10:35< celticminstrel> I'm probably not the best person to answer this, anyway.
20160913 21:10:46< shadowm> Also, the cursor's color scheme seems to clash against everything else. It's highly-visible, sure, but that's on account of it being completely discordant color-wise.
20160913 21:11:30< shadowm> Like someone wearing reflective clothing in a funeral.
20160913 21:11:48< celticminstrel> You mean that bright orange stuff worn by traffic controllers?
20160913 21:12:18< tad_> I'd have to re-enable color cursors to render an opinion :)
20160913 21:13:00< shadowm> celticminstrel: Yes.
20160913 21:13:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160913 21:15:26< celticminstrel> Incidentally, apart from a minor background issue, the GUI1 scrolling seems pretty smooth to me. Just saying.
20160913 21:15:54< celticminstrel> My auto-scrolling seems slightly choppy, I guess. I'll try a timer of 50 instead of 100.
20160913 21:18:53< celticminstrel> This commit will also have the happy side-effect of fixing mattsc's build.
20160913 21:21:01-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 255 seconds]
20160913 21:21:52-!- lobby [~wesnoth@wesnoth/bot/lobby] has joined #wesnoth-dev
20160913 21:21:52-!- Topic for #wesnoth-dev: 1.13.6 planned for late September | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160913 21:21:52-!- Topic set by vultraz [~chatzilla@wesnoth/developer/vultraz] [Sun Sep 11 23:24:46 2016]
20160913 21:21:52[Users #wesnoth-dev]
20160913 21:21:52[ _laco       ] [ celticminstrel ] [ Gambit    ] [ Jetrel_bot   ] [ nurupo    ] [ tad_     ] 
20160913 21:21:52[ abruanese   ] [ clavi          ] [ gfgtdf    ] [ kidneb       ] [ oldlaptop ] [ TC01     ] 
20160913 21:21:52[ aeth        ] [ crimson_penguin] [ Greywhind ] [ knotwork     ] [ Polsaker  ] [ TC02     ] 
20160913 21:21:52[ Aginor      ] [ DDR            ] [ Guest92877] [ lobby        ] [ prkc      ] [ TheJJ    ] 
20160913 21:21:52[ AI0867      ] [ DeFender1031   ] [ heirecka  ] [ Lohengramm   ] [ pydsigner ] [ timotei_ ] 
20160913 21:21:52[ aidanhs     ] [ Duthlet        ] [ higgins   ] [ loonycyborg  ] [ Ravana_   ] [ tomreyn  ] 
20160913 21:21:52[ ancestral   ] [ elias          ] [ horrowind ] [ matthiaskrgr_] [ Rhonda    ] [ vincent_c] 
20160913 21:21:52[ APic        ] [ EliDupree      ] [ irker231  ] [ mattsc       ] [ shadowm   ] [ vultraz  ] 
20160913 21:21:52[ Appleman1234] [ Elsi           ] [ Ivanovic  ] [ midzer       ] [ shikadibot] [ Yaiyan   ] 
20160913 21:21:52[ atarocch    ] [ Elvish_Hunter  ] [ iwaim__   ] [ miniplane    ] [ Sirp_     ] [ zookeeper] 
20160913 21:21:52[ bumbadadabum] [ enchi          ] [ janebot   ] [ mjs-de       ] [ Soliton   ] 
20160913 21:21:52[ celmin      ] [ esr            ] [ Jetrel    ] [ new_one      ] [ stikonas  ] 
20160913 21:21:52-!- Irssi: #wesnoth-dev: Total of 70 nicks [0 ops, 0 halfops, 0 voices, 70 normal]
20160913 21:21:58-!- Channel #wesnoth-dev created Tue Jan 27 05:28:41 2009
20160913 21:22:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 265 seconds]
20160913 21:23:01 * mattsc will be happy with that
20160913 21:23:03-!- Irssi: Join to #wesnoth-dev was synced in 78 secs
20160913 21:23:39< mattsc> On the other hand, ugh, mattsc doesn’t know enough C++ for figuring out this tunnel thing.
20160913 21:23:59< celticminstrel> Need help with something in particular?
20160913 21:24:20< mattsc> Probably.  But I am out of time right now.
20160913 21:27:19< celticminstrel> Looks like the max speed in GUI1 is faster than 200 px/s, so I'm going to allow 25-400 instead of 50-200.
20160913 21:27:57-!- Netsplit *.net <-> *.split quits: celticminstrel, horrowind, Appleman1234, stikonas, Greywhind
20160913 21:28:15-!- Netsplit over, joins: horrowind, Greywhind
20160913 21:28:26-!- Netsplit over, joins: stikonas
20160913 21:28:45-!- Netsplit over, joins: celticminstrel
20160913 21:29:38< irker231> wesnoth: Celtic Minstrel wesnoth:master 1af1932b376d / src/gui/dialogs/ (end_credits.cpp end_credits.hpp): Enable variable scrolling speed in GUI2 end credits https://github.com/wesnoth/wesnoth/commit/1af1932b376d11507302f07c50553095f54f45f3
20160913 21:29:53< celmin> Oh, whoops, forgot to change the min and max. Whatever.
20160913 21:30:02< celmin> vultraz: Let me know if I should do that, I guess.
20160913 21:30:19< celmin> Also, let me know if that's smooth enough for you.
20160913 21:31:56< Aginor> gfgtdf: I'm not actively working on it, but it contains changes that are useful and I'd prefer to keep
20160913 21:32:15< gfgtdf> Aginor: so its not completeley merged yet ?
20160913 21:32:41< Aginor> it should *not* be merged, it'll break a lot :)
20160913 21:33:00< Aginor> I need to start over on it, but some of the changes I made are useful
20160913 21:33:09< gfgtdf> Aginor: ok
20160913 21:34:07< gfgtdf> Aginor: you know whats the state of those #ifdef SDL_GPU codes? does it work somwhow?
20160913 21:34:28< Aginor> I'd be extremely surprised if it works
20160913 21:34:40< Aginor> they can be taken out, and I've been meaning to do so
20160913 21:34:50< Aginor> I've just been rather time poor for a while now
20160913 21:35:50-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160913 21:36:22< shadowm> It feels to me like people ask that question at least once a week.
20160913 21:37:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 21:39:52< Aginor> yeah
20160913 21:40:05< Aginor> I should go and run the codebase through a preprocessor again
20160913 21:40:10< Aginor> end slay it
20160913 21:40:31< Aginor> it's a bit annoying though, last time I did it it liked eating all of our #if 0 defined
20160913 21:40:44< Aginor> arguably, they probably can be removed ;)
20160913 21:40:49-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160913 21:41:21< shadowm> I'd go and hunt for SDL_GPU conditionals myself, but I suspect I'd create conflicts with every other non-production branch that's being worked on.
20160913 21:42:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160913 21:42:22-!- gfgtdf [~chatzilla@x4e363432.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20160913 21:42:47< Aginor> there's probably a good chance of that
20160913 21:42:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 21:44:31-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160913 21:50:53< celmin> Aginor: gfgtdf: It was my impression that the iOS porting guy was using SDL_GPU, but not sure. Still, you might want to check with him before removing it.
20160913 21:51:35 * celmin tries and fails to remember the nick he was using here...
20160913 21:51:52-!- mjs-de [~mjs-de@x4e30284e.dyn.telefonica.de] has quit [Remote host closed the connection]
20160913 21:52:04-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 255 seconds]
20160913 21:52:17< Aginor> celmin: noone is maintaing that code, I'm willing to bet good money that it will not even compile
20160913 21:52:58< Aginor> celmin: I've asked repeatedly, and nobody has told me that it's used before
20160913 21:53:22< celmin> The iOS porting guy showed up fairly recently.
20160913 21:53:57< shadowm> gfgtdf: So, could you fix that bug where starting Wesnoth with -e in the command line crashes due to dereferencing a null pointer?
20160913 21:58:44< celmin> The person who showed up about an iOS port is jswensen.
20160913 21:58:44< shadowm> I'm asking because I didn't see an acknowledgement of the issue in my backlog, though it could've fell through the netsplit cracks.
20160913 21:58:50< shadowm> *fallen
20160913 22:00:33< Aginor> celmin: ok...
20160913 22:00:53< Aginor> celmin: does that mean that we now need to maintain that thing too?
20160913 22:00:59< celmin> Not sure.
20160913 22:01:47< Aginor> I thought the ios port was stuck at 1.10 or something as well
20160913 22:03:18< celmin> He was last seen August 30...
20160913 22:03:36< celmin> I think the idea is to redo the iOS port for 1.14, or something.
20160913 22:04:11< shadowm> Aginor: https://forums.wesnoth.org/viewtopic.php?f=62&p=600567#p600567
20160913 22:05:02< celmin> I'm not sure if jswensen has a forum account. Perhaps vultraz would know.
20160913 22:06:28< Aginor> shadowm: I'm trying to not access the web resources from work :/
20160913 22:06:57< celmin> Aginor: It's just the "new iOS port dev needed" announcement from vultraz.
20160913 22:06:59< Aginor> is that the post asking for a new ios maintainer?
20160913 22:07:02< Aginor> right
20160913 22:07:02< shadowm> Yes.
20160913 22:07:04< celmin> Yeah that
20160913 22:07:23< shadowm>     set_path(): //home normalized to //home/home/shadowm/src/wesnoth
20160913 22:07:26< shadowm> What the crap?
20160913 22:07:37< celmin> What? o.o
20160913 22:07:48< shadowm> fs::normalize_path() does that somehow.
20160913 22:08:07< Aginor> that seems silly
20160913 22:08:17 * Aginor goes to acquire coffee
20160913 22:08:27< shadowm> I'm starting to distrust Boost.Filesystem or the exact implementation of our wrapper around it.
20160913 22:08:37< celmin> The -e crash seems to be because load_data_ does not exist.
20160913 22:08:45< shadowm> Yes.
20160913 22:09:09< celmin> I don't suppose it works if you do -e <file>?
20160913 22:09:29< shadowm> I don't know and it's not really that relevant anyway?
20160913 22:09:54< celmin> Well, if that works, then I think all that needs to be done is check if this pointer is null before dereferencing.
20160913 22:09:57< shadowm> I want to see the editor, not look at a particular file, so I expect the argless version of the option to work without exploding.
20160913 22:10:18 * celmin is currently linking with that change.
20160913 22:10:38< shadowm>   if(normalize_separators) { return bfs::absolute(fpath).make_preferred().string(); }
20160913 22:10:51-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has quit [Quit: leaving]
20160913 22:10:53< shadowm> I suspect this is where my path is getting unexpectedly tampered with.
20160913 22:10:55< celmin>  //home is already absolute, right?
20160913 22:11:12< celmin> With a redundant slash, but still.
20160913 22:11:20< shadowm> /home is a directory, if that's what you're asking.
20160913 22:12:07< shadowm> Even if the redundant slash had an unexpected meaning for Boost.Filesystem, I'm sure it can't be "append the full path to the CWD at the end for no reason at all".
20160913 22:13:15< celmin> Yeah, that's pretty bizarre.
20160913 22:13:56< shadowm>     normalize_path(): normalize //lib64 to //lib64/home/shadowm/src/wesnoth
20160913 22:14:02< shadowm> Yep, that's the bit where it all goes south.
20160913 22:14:40< shadowm> Checking if it's absolute() or make_preferred()...
20160913 22:15:07< celmin> Oh, duh, I got my conditional backwards.
20160913 22:15:15< celmin> Dereferencing only if it's null. 9_9
20160913 22:15:26< shadowm> It's absolute().
20160913 22:16:03< shadowm> "A path that unambiguously identifies the location of a file within a filesystem without reference to an additional starting location. The format is implementation defined."
20160913 22:16:16< shadowm> Well, that doesn't tell me if // has a non-standard meaning for BFS.
20160913 22:17:06< shadowm> Hopefully I can work around this by not passing it the extra path separator, but this seems pretty stupid and defeats the whole purpose of normalize_path().
20160913 22:22:03< celmin> Looks like -e works now.
20160913 22:22:36< celmin> shadowm: This actually sounds like it could be a Boost bug, so maybe try reporting it there? Or using a later version of Boost, maybe.
20160913 22:22:56-!- Appleman1234 [~Appleman1@KD119104108135.au-net.ne.jp] has joined #wesnoth-dev
20160913 22:23:15< shadowm> I consider compiling my own Boost a last-resort option for emergencies.
20160913 22:23:35< shadowm> Plus this is the latest release anyway.
20160913 22:23:38< celmin> Obviously. It takes forever to compile.
20160913 22:23:40< celmin> Ah.
20160913 22:23:57< shadowm> No, it doesn't take long. I don't enable libraries we don't use.
20160913 22:24:25< celmin> I'm confused. Why am I getting "option --data-dir" cannot be specified more than once.
20160913 22:24:34< celmin> When I'm only specifying it once.
20160913 22:24:51< shadowm> It's just that I'm allergic to that poorly-documented build system they use and I don't like having to look at my old notes to get things done instead of being able to deduce things on the spot.
20160913 22:25:40< shadowm> cc1plus: error: unrecognized command line option ‘-Wno-unsused-local-typedefs’ [-Werror]
20160913 22:26:00< celmin> Should be -Wno-unused-local-typedefs
20160913 22:26:00< shadowm> I wonder why GCC only ever decides to complain about this when encountering a more legitimate error in addition.
20160913 22:26:30< shadowm> Oh, it's a typo, I see.
20160913 22:26:33 * celmin also has the XCode build set to suppress warnings about unknown warnings (though maybe only clang supports that).
20160913 22:26:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160913 22:26:47< shadowm> I'm too used to reading people who make typos like that, so I've become desensitivized.
20160913 22:26:58< celmin> So we're blaming gfgtdf?
20160913 22:27:03< celmin> <_<
20160913 22:27:20< shadowm> I wasn't even thinking about Wesnoth but sure.
20160913 22:27:35< shadowm> I'm probably the one who made the typo in the first place.
20160913 22:27:57< shadowm> -            env.AppendUnique(CCFLAGS = Split("-Werror -Wold-style-cast $(-Wno-unused-local-typedefs$)"))
20160913 22:28:00< shadowm> +            env.AppendUnique(CCFLAGS = Split("-Werror $(-Wno-unsused-local-typedefs$)"))
20160913 22:28:04< shadowm> Yep.
20160913 22:28:40< shadowm> Okay, avoiding the redundant path separators solves my issue.
20160913 22:28:44< celmin> What's with the dollar signs...
20160913 22:29:08< shadowm> But it also means my code is responsible for doing some awkward string examination to make sure this doesn't happen.
20160913 22:29:33< shadowm> Instead of things just "working" like I was promised they would with BFS.
20160913 22:29:56< shadowm> So yeah, maybe it's an upstream bug. I could probably check with an earlier version.
20160913 22:30:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 22:30:16< celmin> So, I'm calling ./wesnoth -e <file> where ./wesnoth is a shell-script that calls wesnoth --data-dir=. $@
20160913 22:30:17< shadowm> I suspect they have extensive tests to make sure this kind of thing never makes it into a release, though. :\
20160913 22:30:29< celmin> How are there two data-dirs specified there?
20160913 22:30:41< celmin> Ohh, wait. I bet the -e flag does not work as documented.
20160913 22:31:06< shadowm> I think there's an issue where the last argument to a switch gets interpreted as the trailing data dir option.
20160913 22:31:12< celmin> Yeah.
20160913 22:31:25< celmin> The man-page says that -e accepts an optional file argument.
20160913 22:31:27< shadowm> By which I mean that there are two ways you can pass the data dir in the command line, --data-dir <arg> or as a trailing stand-alone argument.
20160913 22:32:02< shadowm> IIRC the presence of --data-dir does not preclude looking for the latter.
20160913 22:32:48< celmin> Heh, I accidentally opened an RTF file in TextWrangler.
20160913 22:32:54< shadowm> The reason this weird special case exists is because --data-dir didn't exit before, and a lot of documentation told people to pass a path to the data dir at the end when running from the source tree.
20160913 22:33:00< shadowm> *exist
20160913 22:33:05< celmin> Kinda looks a bit like TEX.
20160913 22:33:26< shadowm> Partly because no-one bothered to fix the data dir autodetection logic to take into account the usual CMake build tree layout.
20160913 22:33:37< shadowm> (Until I eventually did.)
20160913 22:34:04< celmin> Still doesn't account for eg MSVC or XCode layouts though.
20160913 22:34:09< celmin> Maybe that's low priority.
20160913 22:34:12< shadowm> Hence partly.
20160913 22:34:55< celmin> I actually kinda think it's a bit silly for build system autodetection to be baked into the code like that.
20160913 22:35:22< shadowm> Anyway, I'm happy to see that there wasn't any such FS traversing logic bug in my untested code and it's just BFS being stupid. <.<
20160913 22:35:59< celmin> Well, it seems that -e <file> does not work, and nor does -el <file> or even -e -l <file>
20160913 22:36:03< shadowm> Like, I just somehow wrote all this code that could never run before thanks to GUI2's awkwardness, and it turns out it works without any issues when its callees aren't being dumb.
20160913 22:36:22< celmin> Oh, wait, maybe I need to quote $@.
20160913 22:36:22< shadowm> I thought I'd have to write at least two more iterations to get it right.
20160913 22:37:00< shadowm> Unquoted $@ will cause issues with paths containing whitespace.
20160913 22:37:44-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160913 22:38:08< celmin> Yeah, that was it.
20160913 22:38:28< celmin> I bet it'll work now even if the data-dir is passed as --data-dir instead of a trailing argument.
20160913 22:39:59< irker231> wesnoth: Celtic Minstrel wesnoth:master b44728c77ea5 / src/game_launcher.cpp: Fix crash when launching with --editor and no file https://github.com/wesnoth/wesnoth/commit/b44728c77ea5a3902eefe6d1bcd8ac44a3f59e82
20160913 22:42:16< irker231> wesnoth: Ignacio R. Morelle wesnoth:master 3a925c85e3e2 / SConstruct: scons: Fix compiler switch typo https://github.com/wesnoth/wesnoth/commit/3a925c85e3e262c8a1036fcdcf703302d32cda05
20160913 22:43:53< shadowm> celmin: That works nicely, thanks.
20160913 22:44:55< shadowm> Looking at how GUI2 struggles with scrolling this list with about 7000 directory entries, I wonder how well that GUI2 credits screen is going to perform.
20160913 22:45:26< celmin> Seemed fine when I tried it.
20160913 22:45:28< shadowm> It does seem to suffer less when scrolling fewer entries at a time, though.
20160913 22:45:52< celmin> I think I saw one or two minor hiccups.
20160913 22:47:15< tad_> Is the scrolling code live on master?
20160913 22:48:18< celmin> Yes, if you uncomment line ~234 in src/about.cpp.
20160913 22:48:57< tad_> ok
20160913 22:51:16-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160913 22:51:27-!- travis-ci [~travis-ci@ec2-54-226-17-125.compute-1.amazonaws.com] has joined #wesnoth-dev
20160913 22:51:28< travis-ci> wesnoth/wesnoth#10907 (master - 1af1932 : Celtic Minstrel): The build has errored.
20160913 22:51:28< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159722686
20160913 22:51:28-!- travis-ci [~travis-ci@ec2-54-226-17-125.compute-1.amazonaws.com] has left #wesnoth-dev []
20160913 22:52:56-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160913 22:56:22< tad_> Loaded my system to 100% CPU and 65% memory.  A almost not-noticable pause to start, smooth enough scrolling looked like about 1/2 a line per step. Might have seen a couple tiny pauses but seemed good
20160913 22:58:30< tad_> Stylistically, I like it better than the original. I'd not complain about it if it were live now and the old code disabled.
20160913 22:59:48< celmin> 100% CPU isn't a problem?
20160913 23:00:46< tad_> Didn't seem to be to me.
20160913 23:01:20< celmin> I also made it disable the timer once it reaches the bottom, so if you want you can then scroll up/down as much as you want.
20160913 23:01:41< tad_> Mind you this is on a VM hosted on Windows 10 and the screen is remoted
20160913 23:01:59< celmin> Remoted?
20160913 23:02:04< celmin> Something like VNC?
20160913 23:02:38< tad_> Windows remote desktop.  Sorta like VNC-lite.
20160913 23:03:05< celmin> If I recally correctly, doesn't remote desktop log out the desktop in favour of the remote control?
20160913 23:03:10< celmin> ^-y
20160913 23:03:52< tad_> No. Normal Windows app I can minimize and do Windows stuff atthe same time. (Never do .. I live on the remote desktop)
20160913 23:04:44< tad_> I like it because it works with Surface RT so I can use the pile of #$%# and sit out on the porch with my morning coffee and do Unix
20160913 23:05:07< Aginor> speaking of which
20160913 23:05:12 * Aginor goes to fetch more coffee
20160913 23:05:45< Aginor> tad_: so no direct RDP server on your VM?
20160913 23:07:02< tad_> No. I have a private VPN set up so I can connect via the iPhone when we're on the road but rarely use it so it usually isn't running.
20160913 23:11:16< Aginor> do you get much mileage out of desktoping from your phone though?
20160913 23:11:35< Aginor> I've never bothered to try it out because it seemed like it'd just be a hassle to use
20160913 23:12:40< tad_> It's a bit slow for gaming but I am usually editing text or reading documents so it's OK for my use.
20160913 23:13:24< tad_> As to hassle, it's just a Wiki connection and start the VPN client-side to tunnel
20160913 23:14:42< tad_> Basically, it's like connect-to-network with an option selected and enter a pass phrase. The RT knowsthe iPhone hotspot so that's automagic
20160913 23:15:26< tad_> Getting it in through my firewalls was the real hassle.
20160913 23:17:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160913 23:18:20< Aginor> so you just use your phone for tethering, not actually driving the machine
20160913 23:18:23< Aginor> ?
20160913 23:18:42< Aginor> I think I've managed to unconfuse myself now
20160913 23:18:43< celmin> Wiki connection?
20160913 23:18:44< tad_> Correct. I use the RT for screen/keyboard/mouse
20160913 23:18:58< Aginor> right, that makes a lot more sense :D
20160913 23:20:50< tad_> Considering the Surface RT is not even good for use as a brick (too light and thin), it's about the only use it sees. Some days, I'm on it all day. Temps around 100F so inside the past couple of months but in a month or so Ill be outside on it a lot.
20160913 23:22:31< Aginor> fair enough
20160913 23:33:19< tad_> Just great. When you don't have the time to check on it, you get an error every time. But when you clear your desk and sit down to actually look into it, it disappears.
20160913 23:33:21 * tad_ sighs
20160913 23:33:53-!- Bonobo [~Bonobo@2001:44b8:254:3200:c932:86f1:c199:faa7] has joined #wesnoth-dev
20160913 23:34:13-!- gfgtdf [~chatzilla@x4e363432.dyn.telefonica.de] has joined #wesnoth-dev
20160913 23:36:18-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160913 23:38:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 23:38:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160913 23:38:15-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160913 23:53:06< tad_> gfgtdf: Have a bit to talk about PR 772 (console errors about no starting positions in the map)? I finally sat down to track down why it was appearing in HttT S17 and, of course, it
20160913 23:53:14< tad_> it's not reapparing.
20160913 23:54:36< gfgtdf> tad_: ok
20160913 23:55:39< tad_> Are there any issues with it? You had a question about the if 0 then 1 .. which might be a meaninless check.
20160913 23:56:23< gfgtdf> tad_: hmm no its fine i think.
20160913 23:56:36< tad_> If there are no human players, then we probably don't need to fall back to side 1 (?) 
20160913 23:56:47< tad_> That's what that line was about.
20160913 23:57:30< tad_> If there are no issues, I'm moving on to rewriting the [terrain_mask] PR per last comments.
20160913 23:58:48< gfgtdf> tad_: maybe we shodul give the player a way to manually specify the vieweing starting position? but on the other hand we already have scroll_to_tile, to this might be not needed.
20160913 23:59:20< gfgtdf> tad_: i wonder whether scroll_to_tile works in prestart events so that the display 'starts' at that position then
--- Log closed Wed Sep 14 00:00:00 2016