--- Log opened Wed Sep 14 00:00:00 2016
--- Day changed Wed Sep 14 2016
20160914 00:00:00< tad_> Most, if not all, scenario start with a [message] which often does a scroll.
20160914 00:00:59< celmin> BTW, did anyone ever get around to making [message] not scroll if the unit speaking is already onscreen?
20160914 00:01:25< tad_> But that's a good question. I'll give it a quick test and report in the PR comments. Perhaps the best action would be to remove that scroll so early and simply document using WML to prescroll if you need to.
20160914 00:01:46< tad_> celmin: It scrolls.
20160914 00:01:56< celmin> So that's a no?
20160914 00:03:06< tad_> celmin: I think so. I was just testing HttT and I always get to one point where it's move/message (repeat 10 times) and it scrolls even though I had it start and stop of the movement on screen.
20160914 00:04:31-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 00:06:17< shadowm>   Okay, despite my best efforts to make everything platform-agnostic, my code doesn't work correctly on Windows (Wine).
20160914 00:07:18< tad_> Not sure Wine is needed. Is it?
20160914 00:07:50< shadowm> Didn't understand the question.
20160914 00:08:03 * celmin guesses he doesn't have access to a real Windows machine.
20160914 00:08:18< shadowm> I'm using Wine because it's less effort to use my usual terminal emulator than boot a VM and use the godawful Windows console.
20160914 00:08:18< tad_> Is Wine support really needed? Ah.
20160914 00:08:29 * tad_ chuckles.
20160914 00:08:52< shadowm> The whole point of Wine is that this kind of thing works almost the same as Windows sans missing features that most Windows applications can't even work with.
20160914 00:08:53< celmin> "wine cmd.exe" >_>
20160914 00:09:18< shadowm> (Such as NTFS junction points.)
20160914 00:09:36< tad_> I hit the reverse trying to build Wesnoth for Linux on Windows Bash. Probably do-able but not fire-and-forget like it is on Arch so I gave up.
20160914 00:10:04< shadowm> I'm not even sure you can easily run an X server on WSL.
20160914 00:10:47< tad_> There's a howto about it. It works if you have a windows X server to handle the screen. 
20160914 00:11:12< shadowm> Like, you don't have any meaningful display devices (?), and I read on the WSL blog that they specifically don't expose a framebuffer device so fbdev is out of the question. The only other option I can think of is talking to an X11 client for Windows.
20160914 00:11:49< shadowm> Or to an X11 server for Windows, rather.
20160914 00:11:53< tad_> Not sure you'd want to use a Linux server and have it compete with windows for the hardware( server and client are reversed on X .. run the server on the remove and the client is the unix box .. don't ask me why
20160914 00:12:53< tad_> Anyway, I read a howto and filed it under 'sure, maybe, someday, but why?'
20160914 00:13:45< shadowm> So the moment I browse to C:\users\shadowm\My Documents I get sent to C:\users\shadowm instead, somehow. Hm.
20160914 00:14:06< shadowm> C:\users\shadowm\My Documents\My Games is fine so it's probably not a whitespace quirk.
20160914 00:14:36< shadowm> lrwxrwxrwx 1 shadowm shadowm 23 Sep 13 21:04 /home/shadowm/.wine/dosdevices/c:/users/shadowm/My Documents -> /home/shadowm/Documents/
20160914 00:14:57< shadowm> Not sure if this small implementation detail is leaking through and messing with normalize_path()'s result...
20160914 00:16:01< tad_> I wonder if the path walking stops at the symlink and return it instead of the target. Obvjously it continues to My Games.  Can you try moving the symlink up a dir level on both ends?
20160914 00:16:04< shadowm> It doesn't seem to be, I can't get a symbolic link to show up.
20160914 00:16:50< shadowm> Which also means My Documents is not in c:\users\shadowm as far as Wesnoth can see.
20160914 00:17:12< shadowm> As in filesystem::get_files_in_dir() at least.
20160914 00:18:24< shadowm> So I guess I can chalk it up to Wine weirdness.
20160914 00:18:43< shadowm> The tree traversing going haywire when reaching C:\, not so much.
20160914 00:19:46< shadowm> It's not even my logic, actually. I'm just using filesystem::is_root().
20160914 00:20:07< shadowm> Oh wait, I wrote that and it's only in this branch.
20160914 00:20:26< shadowm> bool is_root(const std::string& file) { return bfs::absolute(file).parent_path().empty(); }
20160914 00:20:43-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160914 00:20:43< shadowm> So this doesn't yield true for C:\ on Wine (and most likely not Windows either).
20160914 00:21:42< shadowm> Turns out there's a has_parent_path() method I could've used as a shorthand, negated.
20160914 00:22:49-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160914 00:22:58< tad_> It's been a very long time since I did Windows. A quick search for similar issues looks like all old (ca 2011) and your typical new user stuff.
20160914 00:23:08< shadowm> Yep, same result on Windows.
20160914 00:23:21< shadowm> Why are we using Boost.Filesystem, again?
20160914 00:23:54< shadowm> I thought it was supposed to save me the headache of trying to parse paths in a platform-specific way.
20160914 00:23:59< tad_> Because we wanted to add a million lines of code to the compile?
20160914 00:24:23 * tad_ is being a fool.
20160914 00:24:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 00:24:35< shadowm> gfgtdf: How do I check whether I'm on a drive's root using BFS?
20160914 00:25:26< shadowm> bfs::absolute("C:\").parent_path().empty() somehow returns false.
20160914 00:25:38< shadowm> Even though C:\ has no parent in the filesystem namespace.
20160914 00:26:33< gfgtdf> shadowm: hmm maybe 'path.root_name() == path'
20160914 00:26:43< gfgtdf> shadowm: just a guess though
20160914 00:27:13< shadowm> "Returns: root-name, if pathname includes root-name, otherwise path()."
20160914 00:27:19< shadowm> It says "includes", not "is".
20160914 00:27:22-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160914 00:27:59< shadowm> Oh okay, I see what you are trying to tell me.
20160914 00:28:52< shadowm> But in that case I suspect path("\").root_name() will return an empty string.
20160914 00:29:41< shadowm>   is_root(): parent of C:\ is "C:"
20160914 00:29:45< shadowm>   is_root(): parent of \ is "Z:"
20160914 00:29:49< shadowm> Wheeeeeee
20160914 00:29:55< celmin> So WINE is leaking through?
20160914 00:30:13< shadowm> Potentially.
20160914 00:30:21< shadowm> I mean, maybe not.
20160914 00:30:34< shadowm> The thing is at that point BFS is thoroughly convinced that \ is the current working dir.
20160914 00:30:45< shadowm> And the current working dir is Z:\home\shadowm\src\wesnoth.
20160914 00:32:06< shadowm> And get_files_in_dir("\") somehow lists the current working dir's contents instead of Z:\'s.
20160914 00:32:47< shadowm> Actually, it lists <cwd>\.. instead.
20160914 00:32:54< shadowm> God this is confusing.
20160914 00:33:01-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160914 00:33:14< shadowm> Okay, I'll try the root_name() method and see what happens when feeding it \.
20160914 00:33:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160914 00:33:49-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has quit [Quit: "The highest possible stage in moral culture is when we recognize that we ought to control our thoughts." - Charles Darwin]
20160914 00:35:25< gfgtdf> why does std::time_put::put need a std::ios_base& paramter??
20160914 00:36:10-!- atarocch [~atarocch@HSI-KBW-46-223-95-173.hsi.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection]
20160914 00:36:15< shadowm> I'm sorely tempted to make --version's full output part of the default output for all modes.
20160914 00:36:17< gfgtdf> hmm documentaion says ' a stream object that this function uses to obtain locale facets when needed, e.g. std::ctype to narrow characters ' so why does it take a std::ios_base and not a sd::locale if locale factes are what it actuall needs
20160914 00:37:03-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 00:38:00< shadowm>   is_root(): root_name() of \ is
20160914 00:38:10< shadowm> As I suspected, root_name() is unreliable and stupid.
20160914 00:38:20< celmin> I wonder if we still use Boost's mersenne twister rather than the std one.
20160914 00:38:29< shadowm> is_root(): root_name() of C:\ is C:
20160914 00:38:43< shadowm> ******* hell.
20160914 00:38:54< shadowm> I am going to have to hand-parse this crap, aren't I.
20160914 00:39:38< shadowm> I guess I'll check what other people using BFS do.
20160914 00:42:56< shadowm> Can't find anything.
20160914 00:43:19< shadowm> Hand-parse it is.
20160914 00:43:39-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160914 00:44:40< shadowm> Probably a good time as any to decide what to do if someone feeds this a \\?\ or \??\ pátpath.
20160914 00:44:45< shadowm> *path
20160914 00:44:52< shadowm> Or how to deal with UNCs.
20160914 00:45:21< Aginor> UNC?
20160914 00:45:36< Aginor> shadowm: there's no sensible library we can depend on instead?
20160914 00:45:50< shadowm> "Uniform Naming Convention".
20160914 00:46:01< shadowm> I prefer to treat the acronym as a blackbox.
20160914 00:46:12< shadowm> \\SomeComputer\someresource is a UNC.
20160914 00:46:25< shadowm> This is how you refer to networked resources on Windows.
20160914 00:46:54< shadowm> i.e. SMB.
20160914 00:47:42< tad_> "Another 'standard' Microsoft published and everyone else ignored."
20160914 00:48:25< shadowm> I tend to think most people who've used Linux have at least heard of Samba, a popular open-source implementation of SMB.
20160914 00:48:32 * tad_ should change his nic to ResidentCynic
20160914 00:48:46-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160914 00:48:52< shadowm> Windows networking application layer protocol thing.
20160914 00:48:58 * tad_ nods
20160914 00:49:47< tad_> If I'd set it up on this box I could use my 4T drive. But don't need to space so never bothered.
20160914 00:49:50< shadowm> The pseudo-UNC \\?\ paths, and \??\ are two other cans of worms and the source of many a sandbox escape bug.
20160914 00:50:16< celticminstrel> Apple uses Samba now.
20160914 00:50:27< celticminstrel> Or, technically, Samba 2 or something.
20160914 00:50:52< tad_> Everybody uses it because Windows won't do anything else out of the box.
20160914 00:50:53< shadowm> I'm the wrong person to try to explain those, but they basically expose an implementation detail of the NT platform that's normally abstracted away by the Win32 API.
20160914 00:51:13< celticminstrel> No, I mean Apple no longer uses AFP.
20160914 00:51:19< shadowm> Namely, that the filesystem hiearchy is a subset of the larger NT object namespace.
20160914 00:51:21< celticminstrel> As of some version later than I have.
20160914 00:51:33< shadowm> And that drive letters are symbolic links.
20160914 00:56:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160914 00:56:28< Aginor> right...
20160914 00:57:01-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160914 00:59:38< shadowm> I had forgotten there's \\.\ as well.
20160914 01:00:34< shadowm> Well, with this and the existence of UNC it's really not all that surprising that Boost.Filesystem is lacking in something as simple as detecting whether a given path refers to the root of something or not.
20160914 01:01:24< shadowm> \\.\C:\, \??\C:\, \\?\C:\, \??\GLOBALROOT\??\C:\, etc. all refer to the same path after all.
20160914 01:03:05< Aginor> that looks like fun and insanity to me
20160914 01:03:16< Aginor> and a neverending source of security concerns
20160914 01:04:09< shadowm> Testing with Mingw bash on Windows it seems like Mingw's bash (or even libc) might not properly understand some of the ways you can escape the filesystem hiearchy, but it can at least deal with drive letters in \GLOBAL??\ however you refer to it.
20160914 01:04:27< shadowm> It can't deal with sane UNC, however.
20160914 01:04:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 01:04:56< shadowm> Oh wait, it actually can.
20160914 01:05:52< shadowm> I forget that for some reason \\foo doesn't exist whereas \\foo\resource does.
20160914 01:06:15< shadowm> (Unless you're using the Windows UI, in which case \\foo always exists. Yes.)
20160914 01:06:33< vultraz> Aginor: do you have a few minutes to discuss my surface_cleanup branch?
20160914 01:07:11< vultraz> or later?
20160914 01:07:59< shadowm> So I think for the sake of my sanity and since this is a user-driven mechanism I should just say that \ is the root of something.
20160914 01:08:02< shadowm> Nobody cares what.
20160914 01:08:09-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has joined #wesnoth-dev
20160914 01:08:32-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160914 01:08:40< shadowm> And throw an error message if I see a \??\ or \\.\ or \\?\ at the start.
20160914 01:08:43< Aginor> vultraz: I'm at work, so no, not really ;)
20160914 01:08:47< vultraz> ah right
20160914 01:08:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20160914 01:08:57< celmin> vultraz: How's my scrolling look?
20160914 01:08:59< shadowm> Or their forward-slash equivalents that also actually work.
20160914 01:09:07< shadowm> I wasn't expecting that.
20160914 01:09:11< vultraz> celmin: you pushed it?
20160914 01:09:13< celmin> Yes.
20160914 01:09:25< Aginor> my presence is very unreliable while at work as I am actually doing work
20160914 01:09:43< Aginor> I look at irc when there's some dead time, but that's about it
20160914 01:10:59< shadowm> s/bash/ls/
20160914 01:12:37< Aginor> shadowm: I'd suggest disallowing any of the special patterns
20160914 01:12:49< shadowm> <shadowm> And throw an error message
20160914 01:12:51< shadowm> Yes.
20160914 01:13:47< Aginor> maybe even a path starting with \\ but that might be a bit unfriendly to people using network shares
20160914 01:13:58< shadowm> A little conundrum here is that I'll have to stuff all this specialized logic into the file dialog implementation instead of the global filesystem namespace, since it's obviously not generic or safe for validation purposes.
20160914 01:14:22< shadowm> In case someone wanted to reuse our code, that is.
20160914 01:14:58< shadowm> Internally we don't need it since WML/Lua services sandbox paths in a fashion that doesn't allow escaping the filesystem hiearchy.
20160914 01:15:38< Aginor> it's not sounding great to have multiple sandboxing mechanisms in place that do different things though
20160914 01:15:46< Aginor> is there a way to combine them?
20160914 01:15:51< shadowm> So I'm inevitably going back to what I wanted to avoid in the first place -- making the file dialog know stuff about the platform instead of talking to a generic API.
20160914 01:16:04< shadowm> We only have one.
20160914 01:16:10-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 01:16:17< shadowm> The file dialog obviously isn't sandboxed and this is on purpose.
20160914 01:17:20< shadowm> It's never in control of anyone other than the user sitting in front of the screen, so they are supposed to be able to traverse the entire filesystem trying to locate wesnothd or a map file or whatever it is that wants an unrestricted path back.
20160914 01:17:34< Aginor> maybe sandboxing isn't the right term, but validation/filtering
20160914 01:18:48< shadowm> Maybe unifying this stuff could be a future refactor goal., yes.
20160914 01:19:19< shadowm> It also depends on exactly where I take this dialog after I'm done with porting the original GUI1 functionality. I wanted to add a list of drive letters and shortcuts to Wesnoth's most commonly used paths.
20160914 01:19:40< shadowm> And I'm not sure if the latter can be UNCs.
20160914 01:19:50 * shadowm tries running Wesnoth from a UNC.
20160914 01:20:28< shadowm> It dies.
20160914 01:21:36< shadowm> https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20160913_222116.png
20160914 01:22:54< shadowm> So yeah, Boost.Filesystem evidently didn't get us instant UNC support. :p
20160914 01:23:33< tad_>  What do some show \ and some / ??
20160914 01:24:07< shadowm> Because Wesnoth tends to take the cross-platform approach of stuffing / in all paths.
20160914 01:24:37< shadowm> There are very few places that purposely or accidentally get or cause path delimiters to be transformed to the platform's native version.
20160914 01:24:55< shadowm> My file dialog port is one of them.
20160914 01:26:42< shadowm> And you don't really need to do it for anything other than aesthetic reasons, unless you happen to be talking to the NT API.
20160914 01:27:12< shadowm> Or writing a cmd.exe script, because cmd.exe reinvents the wheel with regards to path parsing.
20160914 01:27:18< tad_> Ticket #7404 (new Bugs) Opened 4 years ago Last modified 4 years ago filesystem::canonical fails on UNC paths on Windows
20160914 01:27:42< shadowm> Or working with the graphical shell.
20160914 01:27:47< tad_> Ticket #5448 (new Bugs) Opened 5 years ago Last modified 5 years ago Windows "\\\\?\\", "\\\\?\\UNC\\", and "\\\\.\\" path meta characters
20160914 01:28:13-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160914 01:28:29< tad_> Looks like old, know problems nobody
20160914 01:28:34< tad_> ever looked at 
20160914 01:30:47 * vultraz wonders if the upcoming std::filesystem will be any better
20160914 01:31:30-!- gfgtdf_ [~chatzilla@x4e368107.dyn.telefonica.de] has joined #wesnoth-dev
20160914 01:31:58< celmin> It's based on boost::filesystem, but...
20160914 01:32:00< shadowm> vultraz wonders all the things.
20160914 01:32:37< celmin> That's probably only on the surface.
20160914 01:32:53< tad_> Saw some closed/fixed issues at Microsoft about just this problem for std::tr2:: but skipped because they're not Boost
20160914 01:33:01< celmin> Microsoft, LLVM, and GNU will probably all create their own entirely new implementations.
20160914 01:33:32-!- gfgtdf [~chatzilla@x4e363432.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160914 01:33:40-!- gfgtdf_ is now known as gfgtdf
20160914 01:33:42< celmin> vultraz: Checked the scrolling yet?
20160914 01:33:47< vultraz> checking now
20160914 01:33:50< vultraz> build just finished
20160914 01:34:26< vultraz> it works
20160914 01:34:33< vultraz> but it looks rather more jerky...
20160914 01:34:39< vultraz> I guess we can't fix that
20160914 01:36:12< celmin> More jerky? Seriously?
20160914 01:36:26< vultraz> very slightly
20160914 01:36:51< celmin> I suppose you could put the timer back down to 10, but I doubt it'd really be worth it.
20160914 01:37:03< celmin> (Might also want to double or triple the initial timer.)
20160914 01:37:22< celmin> Also, if you want, the min and max could be changed to 25 and 400 respectively.
20160914 01:37:27< celmin> ^min and max speed
20160914 01:37:58< vultraz> ah, much smoother at timer 10
20160914 01:38:39< vultraz> (obviously we won't get *perfect* smoothness until we have hw acceleration)
20160914 01:39:04< vultraz> but 10 is much better
20160914 01:39:17< celmin> Shrug!
20160914 01:39:19-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 01:39:24< vultraz> about backgrounds
20160914 01:39:34< vultraz> in the old dialog it seemed to change based on distance scrolled
20160914 01:40:01< celmin> Still, I think smoothness really is more about getting the timing consistent rather than not jumping forward.
20160914 01:40:24< vultraz> it divided the size of the string vector by the size of the image vector 
20160914 01:40:33< vultraz> i dunno if we should do that
20160914 01:40:39< celmin> Sounds good.
20160914 01:41:02< celmin> Though it'd probably be easier to base it on the scroll label's height rather than on the size of the image vector.
20160914 01:41:08< celmin> ^string vector
20160914 01:41:55< vultraz> yeah, we need to refactor the string handling..
20160914 01:42:02< vultraz> after we drop the old version
20160914 01:42:56-!- irker231 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160914 01:43:03< vultraz> or could do it now
20160914 01:43:08< vultraz> if it's dialog-local
20160914 01:53:31-!- gfgtdf [~chatzilla@x4e368107.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160914 01:58:16< celmin> vultraz: I think it's better to be processing a config rather than a vector of strings.
20160914 01:58:24< vultraz> yes
20160914 01:58:27< vultraz> exactly
20160914 01:58:59< shadowm> Oh, I remember why \\?\ exists, it's to break out of the Win32 path limit of 260 characters.
20160914 01:59:18< celmin> I don't think we need to keep the old version around.
20160914 01:59:20< shadowm> And expose implementation details while at it.
20160914 02:21:52< shadowm> Google is not only increasingly evil, it's also incompetent.
20160914 02:22:16< celmin> Oh?
20160914 02:22:18< shadowm> I asked it for "windows c check if path is root". It gives me a bunch of irrelevant results, the first of which is the documentation for PathIsRelative on MSDN.
20160914 02:22:31< shadowm> I check that page just in case, guess what.
20160914 02:22:35< shadowm> PathIsRoot() exists.
20160914 02:22:41< celmin> XD
20160914 02:24:35< shadowm> " TRUE for paths such as "\", "X:\" or "\\server\share". Paths such as "..\path2" or "\\server\" return FALSE."
20160914 02:24:43< shadowm> UNCs. Awesome.
20160914 02:25:08< celmin> I'm confused, why is "\\server\" not root?
20160914 02:25:37< shadowm> Because it can contain multiple shares you can enumerate if you use the right API.
20160914 02:25:42< shadowm> And usually does.
20160914 02:26:05< shadowm> It's all very abstract if you've not used SMB before, really.
20160914 02:26:53< shadowm> Wait, I guess I'm looking at it backwards myself.
20160914 02:27:10< shadowm> A path is normally considered root if it has no parents, not no children.
20160914 02:27:31< shadowm> I don't know. It's pretty stupid because \\foo really has no parents.
20160914 02:27:56< shadowm> (\??\UNC\foo does, though. But then so do \\foo\share and \??\UNC\foo\share.)
20160914 02:28:35< shadowm> For \\foo\share I guess the operating assumption is that you're looking at what could _potentially_ be a whole drive shared through the netwoork.
20160914 02:30:23< shadowm> And \\foo doesn't seem to be normally enumerateable filesystem-wise.
20160914 02:30:53< shadowm> I don't know, trying to explain this insanity only raises even more questions.
20160914 02:44:33-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160914 02:56:50-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 02:59:28< celmin> So vultraz, what did you think of decreasing the min speed to 25 and increasing max speed to 400?
20160914 03:02:03< celmin> Also vultraz, I think it'd be nice to add a small explanatory note in the corner: "↑ ↓ to adjust speed"
20160914 03:02:25< celmin> (BTW, were the credits speed adjustment keys in the hotkeys list? Are they rebindable?)
20160914 03:03:28< shadowm> Bleh, to use PathIsRoot I have to alter the build configuration.
20160914 03:03:30< shadowm> Curses.
20160914 03:03:39< celmin> Why is this?
20160914 03:04:15< shadowm> Need -lshlwapi.
20160914 03:04:45 * celmin checks and finds that they are. Should probably use register_hotkey instead of a key handler, then.
20160914 03:07:00< shadowm> loonycyborg: How on earth do I add a new platform-specific library -l option to the Wesnoth target?
20160914 03:07:40-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160914 03:15:22< shadowm> Grrr.
20160914 03:15:38< shadowm> I figured it out.
20160914 03:15:43< shadowm> I did not figure it out.
20160914 03:16:21< shadowm> And to make things even more infuriating I have to bear with that stupid scons CPU usage bug.
20160914 03:17:31< celmin> Hm, I can't find the credit scrolling speed hotkeys in prefs…
20160914 03:18:20< celmin> Oh, I misread the source. That's the hotkey to show the credits, from the titlescreen.
20160914 03:18:51 * celmin prods vultraz 
20160914 03:20:45< shadowm> Yeah scons, sure, adding a library totally means you need to recompile all object files.
20160914 03:21:22< celmin> Well, actually, it kinda does.
20160914 03:21:25< shadowm> Or maybe it's because I switched to fast=yes, except that the first time around you didn't seem to care and only tried rebuilding the same missing executable targets.
20160914 03:21:28< shadowm> No, it doesn't.
20160914 03:21:34< shadowm> -l has no implications for object files.
20160914 03:21:40< celmin> …okay, I guess not so much adding a new one as swapping out a version, but...
20160914 03:22:04< celmin> Yeah okay, I guess merely adding a lib doesn't mean a recompile.
20160914 03:22:21< mattsc> Oh ...
20160914 03:22:26< celmin> Hi?
20160914 03:22:39 * mattsc realizes that he doesn’t need to understand the part he doesn’t understand.
20160914 03:22:44< mattsc> Hi
20160914 03:22:45< celmin> Amazing!
20160914 03:24:00< mattsc> Because the only place where get_teleport_locations() is called with the ignore_units parameter is from wesnoth.find_path() in Lua.
20160914 03:26:38< shadowm> I think my compile times might go down significantly if I just use fast=yes in general.
20160914 03:27:22< shadowm> Even if that may result in some weird and ugly situations if the system libraries change.
20160914 03:31:56< shadowm> Well, I can detect C:\ as root now.
20160914 03:32:20< shadowm> Hmph.
20160914 03:32:46< shadowm> I need to make it so entering a path in the input box and pressing Enter doesn't just close the dialog with the current selection.
20160914 03:39:27< shadowm> I guess I can just check whether the input box matches the selection, and if not do the thing.
20160914 03:40:55< shadowm> Unless textboxes can have retvals... seems not.
20160914 03:41:20-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 03:51:40-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160914 04:00:45< celmin> shadowm: You can call window.set_enter_disabled() if you don't want enter to close the dialog.
20160914 04:01:09< celmin> Not quite sure if that's what you need, mind you...
20160914 04:01:54< shadowm> Not really.
20160914 04:11:25-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 04:12:31-!- JyrkiVesterinen [~JyrkiVest@87-100-182-107.bb.dnainternet.fi] has joined #wesnoth-dev
20160914 04:14:18< vultraz> shadowm: what should enter do?
20160914 04:14:32 * celmin prod vultraz 
20160914 04:14:38< vultraz> celmin: what?
20160914 04:15:04< vultraz> [13:59:28]	celmin	So vultraz, what did you think of decreasing the min speed to 25 and increasing max speed to 400?
20160914 04:15:05< vultraz> [14:02:03]	celmin	Also vultraz, I think it'd be nice to add a small explanatory note in the corner: "↑ ↓ to adjust speed"
20160914 04:15:07< vultraz> [14:02:25]	celmin	(BTW, were the credits speed adjustment keys in the hotkeys list? Are they rebindable?)
20160914 04:15:09< vultraz> why
20160914 04:15:10< vultraz> fine
20160914 04:15:12< vultraz> no
20160914 04:15:58< celmin> About why, mainly because it feels like the fast speed in the new credits is significantly slower than the fast speed in the old credits, and decreasing the minimum is really only a balance thing.
20160914 04:17:00< celmin> About the second, you do it or me?
20160914 04:17:14< vultraz> me
20160914 04:17:19< celmin> 'kay
20160914 04:17:30< pydsigner> It'd be nice if the down key scrolled up
20160914 04:17:37< celmin> What.
20160914 04:18:22< pydsigner> s/down/up/
20160914 04:18:47< shadowm> vultraz: If the user entered the path to a different dir in the input box, switch to it. If the user entered a path to a file in the input box, close the dialog returning that.
20160914 04:19:02< celmin> Meh.
20160914 04:19:18< shadowm> In the first iteration of the dialog, anyway, since I'm considering making it possible in the future to use the dialog to select directories instead of files.
20160914 04:19:32< shadowm> Even though nothing requires such functionality right now.
20160914 04:19:41< vultraz> shadowm: right now the text box has no general-purpose Enter handler
20160914 04:19:50< vultraz> I recommend you add such a thing to the widget
20160914 04:20:16< shadowm> I doubt that'll work anyway? Surely the dialog twindow would get the event first.
20160914 04:20:43< celmin> Depends on how the signals are connected.
20160914 04:20:45< vultraz> not if it's set up correctly.
20160914 04:20:57< shadowm> I may consider it at a later time. Right now my priority is getting the dialog done, then refactoring and adding new bells and whistles.
20160914 04:21:06< vultraz> alright, I'll do it
20160914 04:21:08< celmin> Like, which position is passed (eg front_post_child).
20160914 04:21:24< shadowm> (Which means you will see the dialog land first without any new functionality.)
20160914 04:21:49< vultraz> No problem
20160914 04:21:56< vultraz> The goal is to reduce GUI1 
20160914 04:24:21-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160914 04:24:33-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160914 04:28:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 04:32:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160914 04:32:48-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160914 04:45:21-!- Kwandulin [~Miranda@p200300760F2C71AFC42C0BF7B50289D8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160914 04:58:38-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160914 05:01:46-!- JyrkiVesterinen [~JyrkiVest@87-100-182-107.bb.dnainternet.fi] has quit [Quit: .]
20160914 05:09:02-!- prkc [~prkc@46.166.138.147] has quit [Remote host closed the connection]
20160914 05:12:24-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 05:15:45-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit]
20160914 05:25:33< vultraz> hm
20160914 05:25:35-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160914 05:25:52< vultraz> I cannot make a special enter handler work without disabling window enter...
20160914 05:26:16< celticminstrel> You could change the window handler to be post_child. I think it's currently pre_child.
20160914 05:28:39< vultraz> ah, this seems to work
20160914 05:28:51< vultraz> window wa sregistering its key callback in 2 places
20160914 05:28:56< vultraz> default and back_pre
20160914 05:29:31< vultraz> removed the default and used back_post
20160914 05:29:41< vultraz> which I *think* makes sense
20160914 05:29:52< vultraz> since window keys should be considered last
20160914 05:30:55< vultraz> hm
20160914 05:31:33< vultraz> though that does seem to break enter selection of initial list items in some dialogs
20160914 05:31:35 * vultraz ponders
20160914 05:39:11 * shadowm facepalms.
20160914 05:39:28< shadowm> This is C++11. I no longer need this stupid verbose utils::string_map boilerplate for vgettext().
20160914 05:42:56< shadowm> Do we have a convention for logging domains for GUI2 dialogs?
20160914 05:43:54< shadowm> src/gui/dialogs/multiplayer/mp_change_control.cpp:static lg::log_domain log_gui("gui/dialogs/mp_change_control");
20160914 05:44:01< shadowm> Seems like this is the only dialog with a custom log domain.
20160914 05:44:27< shadowm> src/gui/dialogs/lua_interpreter.cpp:static lg::log_domain log_lua_int("lua/interpreter");
20160914 05:44:30< shadowm> And... this.
20160914 05:47:17< celticminstrel> That sounds like a "no". :P
20160914 05:47:38-!- iwaim__ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has quit [Ping timeout: 265 seconds]
20160914 05:50:46-!- iwaim__ [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20160914 05:51:55-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160914 05:55:02< shadowm> Oh man, more normalize_path() insanity.
20160914 05:58:36< shadowm> normalize_path("C:'", true) yields <cwd>\'.
20160914 05:59:01< shadowm> Looks like whenever in doubt, BFS throws the current working path into the mix.
20160914 05:59:11< shadowm> In random places.
20160914 05:59:34< shadowm> Actually, that's not even <cwd>.
20160914 06:00:05< shadowm> <cwd> is Z:\home\shadowm\src\wesnoth\win32-x-run, I'm getting C:\home\shadowm\src\wesnoth\win32-x-run\'.
20160914 06:00:28< shadowm> Boost.Filesystem doesn't know how to filesystem.
20160914 06:01:35< shadowm> And this is the thing powering most of our filesystem API since version 1.11.19. *headdesks*
20160914 06:02:38< vultraz> so it seems if the window key down event isn't connected to dispatcher in the default position it doesn't pick up event events for toggle panels that haven't been captured or something
20160914 06:02:40< vultraz> hm
20160914 06:03:25< vultraz> what IS the default position
20160914 06:04:01< vultraz> seems to be back_child
20160914 06:04:13< vultraz> hm..
20160914 06:04:23< vultraz> you would think this'd work then..
20160914 06:04:47-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160914 06:04:49< vultraz> hmm
20160914 06:04:55< vultraz> actually, the event fires
20160914 06:05:21< vultraz> BUT the window closes
20160914 06:05:39< vultraz> ok
20160914 06:06:06< vultraz> the event does NOT fire if the window binds back_child and back_pre_child
20160914 06:06:07< vultraz> makes sense
20160914 06:06:15< vultraz> bpc would fire before front_child
20160914 06:06:24< vultraz> let's move that to back_post
20160914 06:06:41< shadowm> https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20160914_030621.png
20160914 06:07:08< shadowm> Haven't wired in the logic to blacklist the namespace escape prefixes.
20160914 06:07:43< vultraz> what's wrong with the text o_O
20160914 06:08:13< vultraz> the text looks absolutely horrendous 
20160914 06:09:15< shadowm> Wine doesn't have the same taste in fonts as you, evidently.
20160914 06:09:31< shadowm> I have no idea, to be honest, considering that Wine internally uses FreeType, same as Cairo on X11.
20160914 06:10:04< vultraz> that's what it looks like if i enable alpha blending for text surfaces
20160914 06:10:14-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160914 06:10:16< shadowm> It's probably some pixel format shenanigans going on in the DirectDraw implementation.
20160914 06:10:31< shadowm> Actually, no, not DirectDraw.
20160914 06:10:38< shadowm> Cairo should be using GDI I think.
20160914 06:10:52< shadowm> Unless it's aware of DirectWrite, which seems doubtful.
20160914 06:12:05< shadowm> Okay, so I can browse to \\?\C:\, but not to \??\C:\, probably because the filesystem API is mangling it in some way.
20160914 06:12:29< shadowm> Ah yes, I have the issue right in front of me.
20160914 06:12:42< shadowm> It's turning it into C:\??\C:\.
20160914 06:12:59< shadowm> \\.\C:\ is also browseable.
20160914 06:13:33< shadowm> So I guess BFS can deal with the pseudo-UNCs but not with \??\.
20160914 06:14:27< shadowm> No BFS, \\nanacore is not \\nanacore\Users\shadowm.
20160914 06:14:30< shadowm> Sigh.
20160914 06:14:31< vultraz> goooddd dammit.
20160914 06:14:35< vultraz> halt is not halting
20160914 06:14:39< vultraz> Y U NO HALT
20160914 06:14:50< shadowm> I can browse to share UNCs!
20160914 06:16:01< shadowm> And PathIsRoot() indeed considers those to be roots.
20160914 06:16:16< shadowm> But not \\?\C:\ or \\.\C:\.
20160914 06:16:21< shadowm> gg Microsoft.
20160914 06:16:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 06:17:02< shadowm> Or Mingw.
20160914 06:18:27< vultraz> i swear this is incredibly annoying
20160914 06:18:52< shadowm> OK, no, it's Microsoft.
20160914 06:19:02< shadowm> I was looking at the wrong wesnoth-debug.exe in Dependency Walker.
20160914 06:19:42< shadowm> It figures, this library is essentially part of the graphical shell services.
20160914 06:20:03< shadowm> So of course it can't deal with stuff that Microsoft likes to pretend doesn't exist until it breaks someone's software.
20160914 06:20:35-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160914 06:20:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160914 06:23:21-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20160914 06:23:21-!- wedge010 is now known as wedge009
20160914 06:27:54< vultraz> this makes no sense
20160914 06:28:12< vultraz> the event fires
20160914 06:28:14< vultraz> but it still closes
20160914 06:28:17< vultraz> despite me setting halt
20160914 06:28:25< vultraz> and it's set to front_child
20160914 06:28:33< shadowm> I _seem_ to have a situation where a GUI2 label shrinks each time but it never grows.
20160914 06:29:00< vultraz> does that label have horizontal_grow = "true"
20160914 06:29:02< vultraz> ?
20160914 06:29:16< shadowm>   error gui/parse: horizontal_grow and horizontal_alignment can't be combined, alignment is ignored.
20160914 06:29:21< shadowm> Oh, it's probably related to this.
20160914 06:29:25< vultraz> yeah
20160914 06:29:29< vultraz> use grow
20160914 06:29:37< shadowm> Except that's the wrong widget.
20160914 06:29:59< shadowm> The problematic one has horizontal_alignment=left and grow_factor=1
20160914 06:30:04< vultraz> yeah
20160914 06:30:05< vultraz> use grow 
20160914 06:30:10< vultraz> not aligmnent
20160914 06:30:22< vultraz> always use grow for labels that intend to change
20160914 06:30:37< vultraz> use alignment only if the label is static
20160914 06:31:03< shadowm> Same issue.
20160914 06:31:37< vultraz> screenshot?
20160914 06:32:01< shadowm> I'd have to record a video.
20160914 06:33:32< shadowm> Ugh, I don't know how to handle the normalize_path() border cases.
20160914 06:33:50< shadowm> Turns out they go beyond the redundant path separators case.
20160914 06:34:13< shadowm> I'll have to cut down on usages of normalize_path() instead.
20160914 06:36:49< vultraz> ok what...
20160914 06:36:56< vultraz> the window handler fires AFTER
20160914 06:36:58< vultraz> AFTER
20160914 06:37:55< vultraz> the text box handler sets handled and halt to true, so it should stop there
20160914 06:43:26< vultraz> sometimes this shit just makes NO sense
20160914 06:45:47-!- Ivanovic [~ivanovic@p579FB681.dip0.t-ipconnect.de] has quit [Changing host]
20160914 06:45:47-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160914 06:48:02-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160914 06:50:05-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160914 06:54:37-!- Kwandulin [~Miranda@p200300760F2C71AFC42C0BF7B50289D8.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20160914 06:58:19< shadowm> wesnoth-debug: src/filechooser.cpp:37: int dialogs::show_file_chooser_dialog(CVideo&, std::__cxx11::string&, const string&, bool, const string&, int, int): Assertion `type_a_head.empty() == false' failed.
20160914 06:58:47< shadowm> Okay, let's see what uses this undocumented inconsistently-named parameter and why...
20160914 06:59:12-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160914 06:59:12-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160914 06:59:12-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160914 07:00:19-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160914 07:00:54< shadowm> ...
20160914 07:00:58< shadowm> I want true, not false.
20160914 07:01:03< shadowm> Never mind.
20160914 07:01:44< shadowm> It's like my brain is trying to run away or something.
20160914 07:02:26< shadowm> Seems like at least the wesnothd search function wants that parameter.
20160914 07:02:39< shadowm> I guess it fills in the textbox without actually expecting the file to exist.
20160914 07:03:09< shadowm> Should I implement that parameter, or make an exception for when path does not entirely exist? Urgh.
20160914 07:03:31< shadowm> These execute() functions are already too wordy.
20160914 07:06:18< shadowm> This is the part where I start hating on C++ for not having named parameters.
20160914 07:06:35< shadowm> (Yes, I'm aware of the Boost thingy.)
20160914 07:08:35< vultraz> named parameters? 
20160914 07:09:33< shadowm> Named parameters.
20160914 07:09:44< shadowm> You know, as in parameters with names.
20160914 07:11:06< vultraz> ah, I see
20160914 07:11:30< shadowm> It'd be particularly great for these functions that take a bazillion arguments, some of them with defaults.
20160914 07:11:45< vultraz> That's why I use structs if possible
20160914 07:12:00< shadowm> The classic dilemma is that you have a function call where you want one or two parameters to be their default values, but the ones following them should never be their defaults.
20160914 07:12:41< shadowm> C++ forces you to spell out the defaults in your code and risk causing non-standard behavior in the future.
20160914 07:13:16< shadowm> Just so you can get to the ones you always want to override.
20160914 07:14:02< shadowm> Like, yeah, maybe I should come up with an idiom for a case like this, but then I'll be setting myself apart from the rest of the codebase that embraces C++'s deficiencies in this area.
20160914 07:14:17< shadowm> My class will look unique and weird in a snobbish kind of way.
20160914 07:14:23< vultraz> so?
20160914 07:14:39< shadowm> And annoyingly C++ hasn't adopted C99's named struct initializers.
20160914 07:15:49< shadowm> (In C99 you can do this: struct Foo { int a, int b, int c };   Foo f = { .b = 93, .c = 22, .a = 42 }; )
20160914 07:16:09< shadowm> (And omit fields as you see fit.)
20160914 07:16:41< vultraz> I am aware
20160914 07:16:47< vultraz> I was complaining about that the other day
20160914 07:16:50< shadowm> No doubt it has something to do with coming up with adequate semantics for non-POD types and the new initializer list syntax.
20160914 07:17:56< vultraz> "C++17 library is based on C11 instead of C99" implying c99 was adopted somewhere.. c++14 maybe?
20160914 07:20:14< shadowm> *Library*.
20160914 07:20:28< shadowm> Named struct field initialization is a language feature, not a library feature.
20160914 07:21:42< shadowm> All contemporaneous versions of C++ constitute a different language to C, therefore if they adopt C language features they do so piecemeal.
20160914 07:21:56< shadowm> The exception is the preprocessor -- C++11 adopts the C99 preprocessor.
20160914 07:22:51< vultraz> huh. I just tried building something with a named struct initializer and it build.
20160914 07:22:57< vultraz> (in wesnoth).
20160914 07:23:27< shadowm> (And that was one of the reasons MSVC++ took/is taking forever to become fully C++11 compliant in a strict sense -- because Microsoft has been avoiding C99 support at both language and library level for some reason.)
20160914 07:23:42< shadowm> vultraz: Uh no, it probably didn't.
20160914 07:23:52-!- atarocch [~atarocch@62.134.204.4] has joined #wesnoth-dev
20160914 07:24:08 * vultraz shrugs
20160914 07:24:19< shadowm> Code?
20160914 07:27:05< shadowm> http://pastebin.com/kc8zARF5 <- What.
20160914 07:27:59< vultraz> required_addon r = { .addon_id = local_item["addon_id"].str(), .outcome = SATISFIED, .message = ""}; <- my test line
20160914 07:29:42< shadowm> It's not standard behavior anyway.
20160914 07:30:26< vultraz> travis would probably bitch if you didn't initialize every member anyway.
20160914 07:30:44< shadowm> It would probably what now?
20160914 07:30:56-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160914 07:31:06< shadowm> It's extremely suspicious and concerning that even with -std=c++98 (which, you know, predates C99) this is a thing.
20160914 07:31:32< vultraz> travis complains about missing field initilizers or something
20160914 07:31:40< shadowm> What other non-standard features aren't hidden behind the gnu++ modes, I wonder?
20160914 07:32:03< shadowm> I believe travis uses GCC 4.9 still, doesn't it?
20160914 07:32:16< vultraz> 4.8 I think
20160914 07:32:23< shadowm> Huh, GCC 5.
20160914 07:32:31< vultraz> wait it uses 5?
20160914 07:33:00< shadowm> Okay, only for a C++1y build configuration that apparently exists?
20160914 07:33:14< vultraz> and fails
20160914 07:33:29< shadowm> But still, non-standard behavior. Bad.
20160914 07:33:49< shadowm> Basically you aren't guaranteed that it's not going to be dropped by a future compiler version, or that it behaves consistently across all compilers.
20160914 07:34:25< shadowm> In one compiler you may get rainbows and ponies, and in another you get blood and zombies.
20160914 07:34:59< vultraz> so seems to happen
20160914 07:35:20< vultraz> a lot of stuff that passes my compiler doesn't pass travis or celticminstrel's
20160914 07:35:47< shadowm> In practice that also happens because compilers have different notions about how to go about implementing the standard library.
20160914 07:35:48< vultraz> plus we still have to support the old MSVC2013
20160914 07:36:07< shadowm> IIRC the standard doesn't say much with regards to things like which headers should depend on which headers.
20160914 07:36:21< shadowm> That often bites people in the rear when doing cross-platform and cross-vendor deployments.
20160914 07:36:54< shadowm> Language features are generally more consistent across the board, unless you are dealing with unspecified or undefined behavior.
20160914 07:37:12< shadowm> Like, for example, the size of long.
20160914 07:37:34< shadowm> Or whether long long exists, if you are targeting C++98.
20160914 07:38:58< shadowm> Or whether it's possible to write to a function pointer.
20160914 07:41:49< shadowm> Or for that matter, what const really does and when const_cast is safe.
20160914 07:44:02< shadowm> I mean, strictly speaking, using const_cast is always safe.
20160914 07:44:17< shadowm> Writing to its result, however, isn't.
20160914 07:44:55< shadowm> A const object, as far as you know (and the thing is you can't easily find out) might live in read only memory.
20160914 07:45:26< vultraz> why use const_cast at all
20160914 07:45:44< shadowm> To paper over poorly-designed code, especially library code.
20160914 07:46:21< shadowm> So yeah, if your const_cast target actually originates from a read-only page, and you decide to write to it, you will die.
20160914 07:46:57< vultraz> why doesn't const_cast copy the object to a r/w area?
20160914 07:47:03< shadowm> There's no way to know whether this is the case unless you can accurately trace its origin somehow, and you're still subject to the compiler and platform's whims.
20160914 07:47:17< shadowm> Because that would be beyond the cast operator's scope.
20160914 07:48:00< shadowm> Cast operators generally do not perform active operations. They just return a preexisting value that you can use, with the correct memory alignment and type qualifiers.
20160914 07:49:14< shadowm> And more importantly, copying to a known-good location still doesn't allow you to change the original storage, so it'd be pretty pointless and count as the language lying to you.
20160914 07:49:39< shadowm> "Oh yeah, you can write to this variable. But I can't guarantee that anyone will ever find out of your changes."
20160914 07:50:57< shadowm> And usually, when you're dealing with read-only memory, there's probably no way to make it read-write without acquiring increased execution privileges.
20160914 07:51:55< shadowm> Otherwise you'd be defeating the whole point of having memory protection.
20160914 07:52:42< shadowm> The same thing applies to trying to execute non-executable memory, or writing to executable memory.
20160914 07:53:44< shadowm> Although most of the time, you can do the latter, for convenience reasons.
20160914 07:55:50< shadowm> Well, some of the time.
20160914 08:04:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 08:08:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160914 08:09:01-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 255 seconds]
20160914 08:09:11-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160914 08:10:32-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160914 08:10:43< JyrkiVesterinen> shadowm: AFAIK, desktop operating systems allow every process to change protection of its own memory pages.
20160914 08:11:16< JyrkiVesterinen> Ability to protect pages from writing is intended for catching bugs, not security.
20160914 08:11:43< JyrkiVesterinen> It increases the chance that e.g. a write through a wild pointer crashes the program immediately.
20160914 08:11:44< shadowm> IIRC platforms such as SELinux allow you to forbid applications from doing that.
20160914 08:12:23< JyrkiVesterinen> Imagine the frustation of a wild pointer write happens to corrupt program code, and a long time later (minutes, even hours) the program executes the corrupted code and crashes.
20160914 08:12:27< JyrkiVesterinen> *if
20160914 08:12:47< shadowm> Writing to executable memory can be useful for certain specialized applications, but otherwise it facilitates code injection.
20160914 08:12:53-!- Kwandulin [~Miranda@p200300760F2C71F8C42C0BF7B50289D8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160914 08:13:09< JyrkiVesterinen> JIT compiling is the most important use of writing to executable memory.
20160914 08:14:00< JyrkiVesterinen> Execution prevention (DEP) is intended for security, but AFAIK the process can make pages executable afterwards.
20160914 08:15:09< JyrkiVesterinen> In any case, attackers have a catch-22. They would be able to make pages (e.g. the stack) unprotected if they could run code to do that, but to run code they would first need to unprotect pages.
20160914 08:15:58< JyrkiVesterinen> There are ways around that, such as return-oriented programming (ROP), but DEP achieves its goal of making exploits harder anyway.
20160914 08:16:34< JyrkiVesterinen> With DEP, exploiting a process is not quite as simply as injecting code into the stack and corrupting a single return address.
20160914 08:16:38< JyrkiVesterinen> *simple
20160914 08:27:03< shadowm> Argh I had to publish something on the filesystem API again.
20160914 08:28:48< shadowm> And my code is looking worse by the minute.
20160914 08:29:12< shadowm> This in particular is a massive red flag:   set_path(path());
20160914 08:31:17< shadowm> Oh well. I think I just reached feature parity with the GUI1 version
20160914 08:32:00< shadowm> Except for that type_a_head parameter that I've not decided how to port.
20160914 08:33:52< loonycyborg> shadowm: https://github.com/wesnoth/wesnoth/blob/master/SConstruct#L545 like this
20160914 08:34:33< loonycyborg> but if it's client only perhaps you need to add it to client_env
20160914 08:34:40< loonycyborg> that code iterates over all envs
20160914 08:36:16< shadowm> It's not client only and I already figured it out, thanks.
20160914 08:37:08< shadowm> Ugh.
20160914 08:37:21< shadowm> Okay, now I remember why I came up with the set_foo(foo()) dance.
20160914 08:37:51< shadowm>   A: current_dir_ = /home/shadowm/.wesnoth-1.13/editor  current_entry_ = asa
20160914 08:37:54< shadowm> B: current_dir_ = /home/shadowm/.wesnoth-1.13/editor/asa  current_entry_ =
20160914 08:39:38< shadowm> I guess I'll have to live with the apparent tautology. I'm sure this mess can be improved in some way by someone with more patience.
20160914 08:41:10< shadowm> Oh right, I made this unnecessarily complicated to accomodate for being able to pick directories instead of files.
20160914 08:42:47< shadowm> And I'm making some special cases that I think normalize_path() should resolve by itself? But then again normalize_path() has been more unreliable than a drunk horse thus far.
20160914 08:43:25< shadowm> I'm way out of shape for this. I'll have to make a pull request. <_<
20160914 08:46:28-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160914 08:59:58-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160914 09:04:40-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160914 09:05:33-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 240 seconds]
20160914 09:32:11< shadowm> Ohhh, I was using the wrong horizontal_foo option after all.
20160914 09:32:17< shadowm> I just wasn't looking at the correct widget.
20160914 09:34:54< vultraz> durr :P
20160914 09:34:59< vultraz> so is it working now?
20160914 09:35:15-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20160914 09:35:45< shadowm> No.
20160914 09:35:59< shadowm> Or rather, yes, but not the way I want.
20160914 09:36:45< vultraz> (note that grow allows the *widget* to grow to fit all available space, and as such, the available canvas space, allowing longer content than the initial *text*)
20160914 09:37:05< shadowm> And then the contents get centered or something.
20160914 09:37:17< vultraz> shadowm: can I see a screenshot?
20160914 09:37:21< vultraz> I think I know how to fix that.
20160914 09:37:41< shadowm> https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20160914_063727.png
20160914 09:38:35< vultraz> as I suspected
20160914 09:38:52< vultraz> give the column with the "location" label "grow_factor = 0"
20160914 09:39:02< vultraz> and the label with the other text "grow_factor = 1"
20160914 09:40:20< vultraz> column grow factors control the horizontal growth of columns relative to each other. In this case, you want the left-most column to not grow at all
20160914 09:40:32< vultraz> row grow factors control the same thing, but in a vertical sense
20160914 09:40:47< vultraz> took me a long time to figure that out
20160914 09:42:01< vultraz> an alternate solution is *not* using horizontal_grow = true for the left-most label
20160914 09:42:12< vultraz> but horizontal_alignment = "left"
20160914 09:42:20< vultraz> I *think* that should have the same effect
20160914 09:42:25< vultraz> if not, use grow_factors as above
20160914 09:42:26< shadowm> Had that already, didn't do it.
20160914 09:42:40< shadowm> Your solution will probably work if my memory serves.
20160914 09:43:18< shadowm> Every time I figure this stuff out I forget it shortly afterwards because it's so convoluted.
20160914 09:44:03< vultraz> Do remember the grow_factor stuff
20160914 09:44:04< shadowm> Yep, your first solution works. Thanks.
20160914 09:44:16< shadowm> No, I'll certainly forget it again.
20160914 09:44:18< vultraz> It's very handy.
20160914 09:44:32< vultraz> Also keep in mind one should never have to use grow_factors other than 0 and 1.
20160914 09:44:44< vultraz> one can, but it's rather functionally useless if you know what you're doing
20160914 09:45:01< shadowm> And with that the UI part of the PR is ready.
20160914 09:46:04< shadowm> *WML
20160914 09:46:45< vultraz> don't forget to add the new dialog to the lists of excluded tests
20160914 09:46:53< shadowm> Why?
20160914 09:47:10< shadowm> Like... why _excluded_.
20160914 09:47:23< vultraz> Either exclude it or code the proper test
20160914 09:47:37< vultraz> Don't not do either.
20160914 09:47:57< vultraz> or travis will croak
20160914 09:48:54< shadowm> OK, I think it's time I publish the first iteration of the code.
20160914 09:49:24< vultraz> btw, why does your text suddenly look better
20160914 09:52:46< shadowm> Because the screenshot that gave you an aneurysm was from Wine.
20160914 09:53:01< shadowm> Any other screenshots are from either Windows 8.1 or X11.
20160914 09:53:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 09:54:11< shadowm> Okay, so how do I go about tidying this up... http://pastebin.com/raw/vq763yJG
20160914 09:54:56< shadowm> I guess I'll squash the whole thing in another branch and then split it.
20160914 09:55:37-!- Kwandulin [~Miranda@p200300760F2C71F8C42C0BF7B50289D8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160914 09:57:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160914 10:08:10< vultraz> so there seems to be a bug in the dispatcher
20160914 10:09:06< vultraz> despite what the code seems to indicate, halt does not halt the execution of further events in the event queue
20160914 10:09:13< vultraz> only prevents events in the next queue..
20160914 10:10:15< shadowm> That probably explains why the halt solution didn't seem tow ork for me.
20160914 10:13:29< shadowm> Wow, the test suite is awful at dealing with SIGINT.
20160914 10:13:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 10:14:42< shadowm>   Window 'file_dialog' registered but not tested.
20160914 10:14:48< shadowm> I just added a test, what.
20160914 10:15:12< shadowm> Oh, never mind.
20160914 10:15:21< vultraz> halt is handled here.. https://github.com/wesnoth/wesnoth/blob/master/src/gui/core/event/dispatcher_private.hpp#L451 and unless break works differently than I know the problem isn't there...
20160914 10:15:22< shadowm> I'm running the -O3 test suite, I built the -O0 one.
20160914 10:15:26-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160914 10:15:42< JyrkiVesterinen> vultraz, the implementation of the halt parameter is here: https://github.com/wesnoth/wesnoth/blob/master/src/gui/core/event/dispatcher_private.hpp#L397
20160914 10:15:43< shadowm>     *** Error in `./test-debug': free(): invalid pointer: 0x00000000033e30af ***
20160914 10:15:46< shadowm> Yikes.
20160914 10:16:04< vultraz> JyrkiVesterinen: we're looking in the same place :P
20160914 10:16:10< JyrkiVesterinen> If halt and handled are set to true, fire_event() returns immediately.
20160914 10:16:16< vultraz> yes
20160914 10:16:36< vultraz> one must conclude this has something to do with something else
20160914 10:16:39< shadowm> Pretty sure this isn't my doing: http://pastebin.com/wxvP64HW
20160914 10:16:50< JyrkiVesterinen> Maybe a different event?
20160914 10:16:50< vultraz> perhaps because this is in two different widgets..
20160914 10:17:05< vultraz> I wonder...
20160914 10:17:19< shadowm> So, yeah. Tests. I guess I won't be able to find out whether the filesystem API tests I just added pass.
20160914 10:18:11< shadowm> Not until I publish the thing and wait a million years for Travis to build and hopefully not hit the same bug.
20160914 10:18:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160914 10:18:22< vultraz> one would think pre_child would handle this case sufficiently
20160914 10:18:29< vultraz> ttext_box has no children
20160914 10:19:35< vultraz> but, no
20160914 10:19:41< vultraz> the event never fires
20160914 10:19:43< vultraz> perhaps..
20160914 10:20:28< vultraz> maybe the event is dispatched through twindow
20160914 10:20:54< shadowm> I can produce an -O3 build from scratch in 3 minutes.
20160914 10:21:03< shadowm> From relatively scratch, anyway.
20160914 10:21:25< shadowm> :V And yet -O0 takes about 10 minutes.
20160914 10:21:35< vultraz> :|
20160914 10:22:02< shadowm> Maybe I'm hitting an HDD bottleneck there and I just don't notice since everything else doesn't use the HDD.
20160914 10:22:06< JyrkiVesterinen> -O0 is probably IO-bound. Unoptimized object files with debug information are quite large.
20160914 10:22:39< shadowm> Yeah, but I didn't think my drive was that slow.
20160914 10:22:57 * vultraz :|
20160914 10:23:16< shadowm> Well, the good news is that the -O3 test suite doesn't hit the memory corruption bug that vultraz is purposely ignoring.
20160914 10:23:43< shadowm> The bad news is:  src/tests/test_filesystem.cpp(53): error: in "filesystem/test_fs_base": check is_root("/../") has failed
20160914 10:25:08< shadowm> On this platform it's literally just bool is_root(const std::string& path) { return !bfs::absolute(path).has_parent_path(); }
20160914 10:25:19< shadowm> So absolute() is not doing what I expect it to do.
20160914 10:25:37< vultraz> how am I supposed to know what's causing the memory bug :/
20160914 10:26:02< shadowm> You're the head maintainer, so don't ask me.
20160914 10:26:03< loonycyborg> pretty sure that gremlins are causing it
20160914 10:26:06< vultraz> it's not my doing.
20160914 10:26:50< shadowm> So okay, how do I make an absolute path with Boost.Filesystem if absolute() doesn't do the job.
20160914 10:26:59< shadowm> How do I Boost.Filesystem.
20160914 10:27:09< vultraz> you make BFS sound horrible
20160914 10:27:19< shadowm> Okay, I see, there's apparently a difference between an absolute and a canonical path.
20160914 10:27:27< shadowm> So what I really want is a canonical path.
20160914 10:27:51< loonycyborg> hmm I have made some functions for that
20160914 10:27:56< shadowm> But then why normalize_path() which I didn't write, uses absolute() instead of canonical()????
20160914 10:28:04< shadowm> The plot thickens.
20160914 10:28:47< shadowm> In fact, nothing in our fs API ever uses canonical() right now.
20160914 10:29:02< shadowm> Even though it seems like it's definitely the thing we should be using.
20160914 10:29:25< shadowm> I suppose it _was_ a rush job after all. :\
20160914 10:29:58< loonycyborg> shadowm: https://github.com/loonycyborg/scons-plusplus/blob/master/src/util.cpp#L103 :P
20160914 10:30:21< shadowm> loonycyborg: Why.
20160914 10:30:31< shadowm> <shadowm> canonical()
20160914 10:30:58< shadowm> Is there some reason I shouldn't actually use canonical()? I need to know this.
20160914 10:31:16< loonycyborg> if filesystem had a function to turn /../ into / I'd be using it I think
20160914 10:31:30< loonycyborg> maybe it didn't have at the time
20160914 10:31:54< shadowm> My tests pass when replacing absolute() with canonical() for is_root().
20160914 10:33:07< vultraz> so, in this case, you're happy with Canonical? :P
20160914 10:33:55< shadowm> I'm not.
20160914 10:34:31< shadowm> I may want to use canonical() for normalize_path() too.
20160914 10:34:40< shadowm> Wait.
20160914 10:34:45< shadowm> unknown location(0): fatal error: in "filesystem/test_fs_base": boost::filesystem::filesystem_error: boost::filesystem::canonical: No such file or directory: "/a/.."
20160914 10:34:54< shadowm> Okay, I guess that's the issue with canonical().
20160914 10:35:09< shadowm> It really absolutely needs everything that's being referenced to exist.
20160914 10:36:48< shadowm> I'm not sure I want to make "THE PATH MUST EXIST" a precondition for is_root().
20160914 10:37:16< shadowm> OTOH I guess I may just return false if it doesn't.
20160914 10:37:23< loonycyborg> ah yes
20160914 10:37:34< loonycyborg> that's why I have custom function
20160914 10:37:44< loonycyborg> I don't want symlink resolution
20160914 10:37:56< loonycyborg> and it making it absolute
20160914 10:41:50-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20160914 10:42:19< loonycyborg> seems it provides stuff I made custom implementations for
20160914 10:42:29< loonycyborg> lexically_relative and lexically_normal
20160914 10:43:04< loonycyborg> shadowm: http://www.boost.org/doc/libs/1_61_0/libs/filesystem/doc/reference.html#lexically_normal
20160914 10:43:14< loonycyborg> that's how you suppress symlink resolution
20160914 10:44:06-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160914 10:44:06-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160914 10:44:06-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160914 10:44:15< loonycyborg> uff that'd set min boost version to 1.60 though
20160914 10:45:21< vultraz> god *dammit* why does the power keep going off
20160914 10:46:49< vultraz> for the record, I am still unable to build with boost 1.60
20160914 10:46:56< vultraz> or 61
20160914 10:47:11< vultraz> and i have no idea why
20160914 10:49:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 10:50:05-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160914 10:54:14-!- matthiaskrgr_ is now known as matthiaskrgr
20160914 10:54:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160914 10:54:45-!- irker951 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160914 10:54:45< irker951> wesnoth: loonycyborg wesnoth:campaignd_asio 47a85151c649 / src/CMakeLists.txt: Update cmake with asio campaignd port sources https://github.com/wesnoth/wesnoth/commit/47a85151c649a56fcad525b543a2cbbe0bfbd474
20160914 10:55:34< vultraz> can you also remove network*.*pp if they're unused
20160914 10:56:24< loonycyborg> hmm ok
20160914 10:58:27< loonycyborg> I converted uses of boost::bind to std::bind and boost::shared_ptr to std::shared_ptr since otherwise it wouldn't compile
20160914 10:59:13< vultraz> obviously 
20160914 11:03:03-!- Guest92877 [~ncourant@sas.eleves.ens.fr] has quit [Ping timeout: 240 seconds]
20160914 11:03:49-!- Guest92877 [~ncourant@sas.eleves.ens.fr] has joined #wesnoth-dev
20160914 11:05:57-!- Guest92877 is now known as nore
20160914 11:09:26-!- Bonobo [~Bonobo@2001:44b8:254:3200:c932:86f1:c199:faa7] has quit [Quit: Leaving]
20160914 11:12:45-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20160914 11:19:43-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160914 11:22:17-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160914 11:22:31-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160914 11:24:02< irker951> wesnoth: loonycyborg wesnoth:campaignd_asio b1d110b95eb9 / src/ (network.cpp network.hpp network_worker.cpp network_worker.hpp tests/main.cpp): Remove old networking stack https://github.com/wesnoth/wesnoth/commit/b1d110b95eb941e921c82ddd9577a1d5e4048bc0
20160914 11:24:04< irker951> wesnoth: loonycyborg wesnoth:campaignd_asio d81e426ac5e4 / changelog: Update changelog https://github.com/wesnoth/wesnoth/commit/d81e426ac5e40d52ff57a9ad80ccc55a8b3bab25
20160914 11:25:12< vultraz> should be good to merge once you rebase out the old merge commits 
20160914 11:25:21< vultraz> or if you don't want to just merge as-in
20160914 11:29:56< loonycyborg> I wanna see travis result first
20160914 11:38:47-!- Kwandulin [~Miranda@p200300760F2C71F8E8B2CEE0A3965A7D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160914 11:44:56-!- travis-ci [~travis-ci@ec2-54-234-117-3.compute-1.amazonaws.com] has joined #wesnoth-dev
20160914 11:44:57< travis-ci> wesnoth/wesnoth#10918 (campaignd_asio - 47a8515 : loonycyborg): The build has errored.
20160914 11:44:57< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159841747
20160914 11:44:57-!- travis-ci [~travis-ci@ec2-54-234-117-3.compute-1.amazonaws.com] has left #wesnoth-dev []
20160914 11:45:13-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has joined #wesnoth-dev
20160914 11:47:29< loonycyborg> hmm clang doesn't seem to have std::chrono
20160914 11:51:31< vultraz> :/
20160914 11:52:43< JyrkiVesterinen> That sounds strange. Clang has had full C++11 support for years. A version without std::chrono has to be very old.
20160914 11:54:25< loonycyborg> clang version 3.5.0
20160914 11:56:24< loonycyborg> need to check, maybe I just forgot the include
20160914 11:57:55< loonycyborg> If I run the same command locally, it works without error
20160914 11:58:07< loonycyborg> maybe some misconfiguration on travis
20160914 11:59:40< JyrkiVesterinen> I checked that <chrono> existed back in Clang 3.0: https://github.com/llvm-mirror/libcxx/tree/release_30/src
20160914 12:01:52< irker951> wesnoth: loonycyborg wesnoth:campaignd_asio 015c1ee3becd / src/campaign_server/campaign_server.cpp: Added explicit include for std::chrono https://github.com/wesnoth/wesnoth/commit/015c1ee3becd910dfd8072c3ce3348db4936bfb8
20160914 12:02:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160914 12:23:18-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has quit [Quit: Leaving]
20160914 12:34:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 12:39:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20160914 12:39:22-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160914 12:42:52< zookeeper> if this is a spambot it's a pretty good one: https://forums.wesnoth.org/search.php?author_id=142438&sr=posts
20160914 12:43:05< zookeeper> the only thing giving it away would be the post in the ambush thread, which is copied from the first page
20160914 12:44:52< zookeeper> well, i guess also the way the posts are spaced only minutes apart
20160914 12:47:41< Ravana_> unlike most spambots, it has Joined:31 minutes ago and Last visited:12 minutes ago
20160914 12:48:00< Ravana_> those tend to have less than 5min later last visited, and never visit again
20160914 12:49:57-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160914 12:49:57-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160914 12:49:57-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160914 12:52:34-!- Kwandulin [~Miranda@p200300760F2C71F8E8B2CEE0A3965A7D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160914 12:54:34-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160914 12:58:43-!- travis-ci [~travis-ci@ec2-54-234-117-3.compute-1.amazonaws.com] has joined #wesnoth-dev
20160914 12:58:44< travis-ci> wesnoth/wesnoth#10920 (campaignd_asio - d81e426 : loonycyborg): The build has errored.
20160914 12:58:45< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159847049
20160914 12:58:45-!- travis-ci [~travis-ci@ec2-54-234-117-3.compute-1.amazonaws.com] has left #wesnoth-dev []
20160914 13:01:40-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160914 13:06:24-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160914 13:12:26-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160914 13:14:09-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160914 13:19:03-!- atarocch [~atarocch@62.134.204.4] has quit [Ping timeout: 240 seconds]
20160914 13:22:27-!- atarocch [~atarocch@62.134.204.4] has joined #wesnoth-dev
20160914 13:41:42-!- travis-ci [~travis-ci@ec2-54-226-17-125.compute-1.amazonaws.com] has joined #wesnoth-dev
20160914 13:41:43< travis-ci> gfgtdf/wesnoth-old#683 (fix_24927 - 706ad0e : gfgtdf): The build failed.
20160914 13:41:43< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/159867929
20160914 13:41:43-!- travis-ci [~travis-ci@ec2-54-226-17-125.compute-1.amazonaws.com] has left #wesnoth-dev []
20160914 13:55:20-!- gfgtdf [~chatzilla@x4e368107.dyn.telefonica.de] has joined #wesnoth-dev
20160914 13:56:45< gfgtdf> does anyone know why write_location_range si so cimplicated i'd think that it just does 'for loc in range do { x << ',' << loc.x+1; y << ',' << loc.y+1 }' but that doesn't seem ot be the case.
20160914 13:59:54< vultraz> not I
20160914 14:04:19-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 248 seconds]
20160914 14:11:07-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160914 14:25:05-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160914 14:32:03< vultraz> so I refactored the new credits screen to parse the config directly
20160914 14:32:16< vultraz> and suddenly the problems about the text not showing went away P_P
20160914 14:38:28-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160914 14:47:52-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160914 14:49:23-!- gfgtdf [~chatzilla@x4e368107.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160914 14:57:23-!- atarocch [~atarocch@62.134.204.4] has quit [Quit: Leaving]
20160914 15:02:15-!- irker951 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160914 15:10:02-!- SeamusFD [~SeamusFD@72-161-184-164.dyn.centurytel.net] has joined #wesnoth-dev
20160914 15:10:54-!- SeamusFD [~SeamusFD@72-161-184-164.dyn.centurytel.net] has quit [Client Quit]
20160914 15:27:55< vultraz> hm... maybe it's due to me screwing up and making the text somewhat shorter?
20160914 15:28:52< vultraz> that seems a possibility :/
20160914 15:42:29-!- Kwandulin [~Miranda@p200300760F2C71F87CAA7DD8C39E0212.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160914 15:47:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 15:51:14-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 244 seconds]
20160914 16:09:41-!- irker559 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160914 16:09:41< irker559> wesnoth: Charles Dang wesnoth:master d6ece4ef5a7f / data/gui/window/end_credits.cfg: End Credits: added explanatory label regarding speed controls https://github.com/wesnoth/wesnoth/commit/d6ece4ef5a7f928216d4012e9c6b7ed127c08829
20160914 16:09:42< irker559> wesnoth: Charles Dang wesnoth:master 04a6384beb51 / data/core/about.cfg: Use bullets for credits spacers instead of asterisks https://github.com/wesnoth/wesnoth/commit/04a6384beb51c9f1bd0eeafb593cfdc2763f5da2
20160914 16:09:43< irker559> wesnoth: Charles Dang wesnoth:master 476027f239f2 / src/ (7 files in 3 dirs): Completely refactored internal handling of credits and enabled new dialog https://github.com/wesnoth/wesnoth/commit/476027f239f2c86169ad088bbfe6024c0ad2d1f6
20160914 16:12:35< vultraz> Still need to address the 'surface not showing' thing, but it works for now.
20160914 16:12:59-!- atarocch [~atarocch@HSI-KBW-46-223-95-173.hsi.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20160914 16:13:14-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160914 16:13:39< vultraz> and I need to re-enable the display of credits in Help
20160914 16:13:58< vultraz> (unless someone decides it's not needed)
20160914 16:14:21-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160914 16:15:30< vultraz> ah, great timing
20160914 16:16:10< vultraz> celticminstrel: I have refactored the internal handling of credits, do review
20160914 16:16:13< vultraz> I'm off tobed
20160914 16:18:54< zookeeper> gfgtdf, well surely it's complicated so that it can write compact ranges instead of listing each location individually? like x=1-10 instead of x=1,2,3,...
20160914 16:20:38-!- JyrkiVesterinen [~JyrkiVest@89-166-109-188.bb.dnainternet.fi] has joined #wesnoth-dev
20160914 16:23:13-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Ping timeout: 265 seconds]
20160914 16:30:28-!- travis-ci [~travis-ci@ec2-54-162-120-232.compute-1.amazonaws.com] has joined #wesnoth-dev
20160914 16:30:29< travis-ci> wesnoth/wesnoth#10925 (master - 476027f : Charles Dang): The build was broken.
20160914 16:30:29< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159922023
20160914 16:30:29-!- travis-ci [~travis-ci@ec2-54-162-120-232.compute-1.amazonaws.com] has left #wesnoth-dev []
20160914 16:31:38< celticminstrel> :(
20160914 16:32:50< irker559> wesnoth: loonycyborg wesnoth:campaignd_asio b52571d8d9f6 / src/tests/main.cpp: Remove use of network::error missed due to conditional compilation https://github.com/wesnoth/wesnoth/commit/b52571d8d9f60fe9ede9445e80f8dac2ce6ae356
20160914 16:36:42-!- mjs-de [~mjs-de@x4e3188f2.dyn.telefonica.de] has joined #wesnoth-dev
20160914 16:43:33< vultraz> *is back*
20160914 16:43:39< vultraz> oh come on, travis :|
20160914 16:44:01< vultraz> I *hope* that just needs an include
20160914 16:44:19< vultraz> *out again*
20160914 16:46:52-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160914 16:48:28< JyrkiVesterinen> According to the build log it seems to be use of a nonstandard extension.
20160914 16:48:30< JyrkiVesterinen> src/gui/dialogs/end_credits.cpp:96:7: error: no member named 'swap' in
20160914 16:48:30< JyrkiVesterinen>       'std::basic_stringstream<char>'
20160914 16:48:30< JyrkiVesterinen>                 str.swap(focus_str);
20160914 16:48:30< JyrkiVesterinen>                 ~~~ ^
20160914 16:49:18< JyrkiVesterinen> Std::swap() might still work here.
20160914 16:49:30< celticminstrel> I suspect not.
20160914 16:49:47< celticminstrel> Streams are non-copyable, if I recall correctly, and swap relies on copying.
20160914 17:02:37-!- Kwandulin [~Miranda@p200300760F2C71F87CAA7DD8C39E0212.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160914 17:04:40< JyrkiVesterinen> For the record, current master compiles just fine with MSVC.
20160914 17:04:59< JyrkiVesterinen> I'll leave fixing the error to someone who can reproduce it themselves.
20160914 17:18:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160914 17:23:17-!- travis-ci [~travis-ci@ec2-54-226-17-125.compute-1.amazonaws.com] has joined #wesnoth-dev
20160914 17:23:18< travis-ci> wesnoth/wesnoth#10926 (campaignd_asio - b52571d : loonycyborg): The build has errored.
20160914 17:23:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159928801
20160914 17:23:18-!- travis-ci [~travis-ci@ec2-54-226-17-125.compute-1.amazonaws.com] has left #wesnoth-dev []
20160914 17:41:45-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160914 17:52:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160914 17:53:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 17:53:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160914 17:53:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 17:55:12-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has quit [Quit: Lost terminal]
20160914 17:57:23-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20160914 17:59:14-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160914 18:08:25-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160914 18:20:33-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160914 18:24:35-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds]
20160914 18:24:35-!- wedge010 is now known as wedge009
20160914 18:25:14-!- Kwandulin [~Miranda@p200300760F2C71F8217990CF65617DC2.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160914 18:27:32-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160914 18:33:11-!- Ivanovic_ [~ivanovic@p4FC53084.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160914 18:33:12-!- Ivanovic_ [~ivanovic@p4FC53084.dip0.t-ipconnect.de] has quit [Changing host]
20160914 18:33:12-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160914 18:33:57-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 244 seconds]
20160914 18:35:05-!- Ivanovic_ is now known as Ivanovic
20160914 18:36:18-!- ancestral [~ancestral@96-82-223-213-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20160914 19:04:06-!- ancestral [~ancestral@96-82-223-213-static.hfc.comcastbusiness.net] has quit [Quit: i go nstuf kthxbai]
20160914 19:12:27-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160914 19:13:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160914 19:36:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160914 19:39:03-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20160914 19:45:11-!- iwaim__ [~iwaim@rasteenie.alib.jp] has quit [Read error: Connection reset by peer]
20160914 19:45:31-!- iwaim [~iwaim@124.146.179.10] has joined #wesnoth-dev
20160914 19:45:38-!- JyrkiVesterinen [~JyrkiVest@89-166-109-188.bb.dnainternet.fi] has quit [Quit: .]
20160914 19:49:40-!- shadowm [~ignacio@baldras.wesnoth.org] has quit [Ping timeout: 255 seconds]
20160914 19:50:29-!- shadowm [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160914 19:55:37-!- Nobun [~nobun@5.170.109.94] has joined #wesnoth-dev
20160914 20:17:48-!- gfgtdf [~chatzilla@x4e368107.dyn.telefonica.de] has joined #wesnoth-dev
20160914 20:26:07< gfgtdf> vultraz: did we drop support for other map borders than 1 ?
20160914 20:29:08-!- mjs-de [~mjs-de@x4e3188f2.dyn.telefonica.de] has quit [Remote host closed the connection]
20160914 20:34:02< irker559> wesnoth: Elvish_Hunter wesnoth:master 0efdd721e2ec / data/tools/GUI.pyw: GUI.pyw: slightly modified layout of wmlxgettext tab https://github.com/wesnoth/wesnoth/commit/0efdd721e2ecf04d726387aba2246d719460fe68
20160914 20:34:03-!- gfgtdf [~chatzilla@x4e368107.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160914 20:34:04< irker559> wesnoth: Elvish_Hunter wesnoth:master 59d815dcf16c / data/ (core/units/undead/Skele_Chocobone.cfg tools/wmllint): wmllint: handle SPECIAL_NOTES_DEFENSE_CAP https://github.com/wesnoth/wesnoth/commit/59d815dcf16c1b57fa08f5c30f0c32b792c4d9db
20160914 20:34:48< loonycyborg> hmm   travis with clang still fails
20160914 20:35:03< loonycyborg> seems boost there lacks support for chrono
20160914 20:38:27-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160914 20:39:57< celticminstrel> What's wrong with std::chrono?
20160914 20:40:40-!- Kwandulin [~Miranda@p200300760F2C71F8217990CF65617DC2.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160914 20:41:28< celticminstrel> (Though... Boost lacking chrono seems weird...)
20160914 20:42:17-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160914 20:54:44-!- travis-ci [~travis-ci@ec2-54-242-123-125.compute-1.amazonaws.com] has joined #wesnoth-dev
20160914 20:54:45< travis-ci> wesnoth/wesnoth#10927 (master - 59d815d : Elvish_Hunter): The build is still failing.
20160914 20:54:46< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159992637
20160914 20:54:46-!- travis-ci [~travis-ci@ec2-54-242-123-125.compute-1.amazonaws.com] has left #wesnoth-dev []
20160914 20:56:03-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160914 20:56:03-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160914 21:05:07-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 21:05:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20160914 21:06:38-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20160914 21:06:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 21:08:36-!- gfgtdf [~chatzilla@x4e368107.dyn.telefonica.de] has joined #wesnoth-dev
20160914 21:13:00-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20160914 21:16:24-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 276 seconds]
20160914 21:28:33-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160914 21:29:00-!- EliDupree [~quassel@2604:a880:400:d0::9bb:2001] has joined #wesnoth-dev
20160914 21:35:32-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has quit [Quit: leaving]
20160914 21:36:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160914 21:40:07< loonycyborg> celticminstrel: take a look at the output yourself. It seems that the boost call simply lacks overload for std::chrono for some reason
20160914 21:40:20< celmin> Oh.
20160914 21:42:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 21:47:09< mattsc> Umm, anybody seen this before:
20160914 21:47:20< mattsc> Caught general exception:
20160914 21:47:20< mattsc> zlib error: unspecified iostream_category error
20160914 21:47:38< mattsc> All version of 1.13 currently crash with this error.
20160914 21:47:45< celmin> Eh?
20160914 21:48:08< mattsc> I updated to Xcode 8 earlier today, but it worked for a little after that, and then all of a sudden ...
20160914 21:48:20< celmin> Clean build doesn't help?
20160914 21:48:47< mattsc> 1.13.2, 1.13.4 and 1.13.5 releases crash with the error too, so I doubt it
20160914 21:48:55< celmin> Oh.
20160914 21:49:11< mattsc> My guess is the Apple mucked around in the system libraries again ...
20160914 21:49:20< celmin> Is zlib bundled into the application package?
20160914 21:49:40< mattsc> Let’s see
20160914 21:51:00< mattsc> There’s libz.1.2.8.dylib, but I don’t think that’s the same, is it?
20160914 21:51:10< celmin> That'd be zlib.
20160914 21:51:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160914 21:52:03-!- Appleman1234 [~Appleman1@KD119104108135.au-net.ne.jp] has quit [Ping timeout: 248 seconds]
20160914 21:55:12< mattsc> Sigh.  Always something new.
20160914 21:56:19< celmin> I dunno if it would work to substitute whatever zlib Apple ships with...
20160914 21:57:26< celmin> I suppose you could ask ancestral, whenever he happens to show up.
20160914 21:58:19< mattsc> Yeah, I don’t know.  Xcode 8 is out brand new.  I at first wasn’t going to update yet, then I changed my mind.
20160914 21:58:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 21:58:41< celmin> Ah.
20160914 22:16:35-!- Appleman1234 [~Appleman1@KD119104112091.au-net.ne.jp] has joined #wesnoth-dev
20160914 22:19:35< mattsc> Well, I guess that means that I am out of business for the time being
20160914 22:21:02< mattsc> What I don’t understand is why it worked for a while after I upgraded, and then it suddenly stopped.
20160914 22:21:18< celmin> :(
20160914 22:41:03< mattsc> I guess the one thing I could try is build all the libraries again with macports and see what happens …
20160914 22:42:02< celmin> I guess...
20160914 22:59:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160914 23:08:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 23:18:23-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160914 23:20:43-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160914 23:28:16< mattsc> Well, I don’t know what to do any more.  If anybody has ideas, please let me know.
20160914 23:28:36< mattsc> Currently, I cannot run any 1.13 version
20160914 23:31:50-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160914 23:33:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160914 23:34:10-!- irker559 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160914 23:34:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160914 23:43:03-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Ping timeout: 265 seconds]
20160914 23:43:54-!- atarocch [~atarocch@HSI-KBW-46-223-95-173.hsi.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection]
20160914 23:49:42-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160914 23:49:45-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Read error: Connection reset by peer]
20160914 23:50:45-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20160914 23:54:35-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160914 23:55:10-!- Nobun [~nobun@5.170.109.94] has quit [Quit: Salve a tutti]
--- Log closed Thu Sep 15 00:00:00 2016