--- Log opened Sun Nov 13 00:00:04 2016
20161113 00:06:06< Aginor> tad_carlucci: hey tad, following up from Friday; I do care, otherwise I wouldn't have asked. I've done some reading on the subject and I haven't seen stronger arguments of semantic grouping of functions into files as opposed to splitting it, and as I said, I still haven't come across any projects actually putting it what you advocate into practise. So any examples would be greatly appreciated :)
20161113 00:08:46< tad_carlucci> Aginor, of the top of my head I'd suggest looking at libc
20161113 00:09:15< tad_carlucci> Boost probably does it, too.
20161113 00:09:50< Aginor> boost is cpp though, that comes with other conventions, which are mainly 1 class + internal helpers per file
20161113 00:11:03< tad_carlucci> That's the point. If you need to class and ALL the helpers, that's fine. But we're talking about many classes per file and a lot of non-class things per file.
20161113 00:11:48< Aginor> we're talking about a mainly c++ project, which a scattering of c-style functions as well
20161113 00:11:57< tad_carlucci> No
20161113 00:12:04< tad_carlucci> We're talking about the linker.
20161113 00:12:37< Aginor> I honestly thoughts we're talking about project organisation here
20161113 00:13:07< tad_carlucci> Well, if you want the linker to do it's job, you have to organize your project to let it do so.
20161113 00:15:31< tad_carlucci> Condider a file with two functions. "A" is small and used a lot. When "A" is used, "B" is not. "B" refers to a lot of other stuff in other files. To link "A" where it's needed the linker load the ENTIRE .o. That means "B" comes along. So it MUST resolve all the external references for "B" even though only "A" was used and none of those references are used.
20161113 00:16:17< tad_carlucci> So, either put "A" and "B" in separate files or enable function-level linking and pray it doesn't bite you when you do so.
20161113 00:17:33< tad_carlucci> The issue I hit was "B" was refering to files in a library not presented to the linker, so they caused link errors. So either move "B" or add all those in so the errors go away.
20161113 00:18:24< tad_carlucci> In large monolythic projects where you're talking about only one program, you won't see the issue. You see it in spades when you're looking at a general-purpose library.
20161113 00:19:00< Aginor> that's a fair point, but wesnoth isn't a general-purpose library
20161113 00:19:30-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 00:20:32< Aginor> someone has howerver in the past chosen to split the compile targets into a number of executables and static libraries that are then added to the respective executables
20161113 00:20:47< tad_carlucci> OK. Then delete the following to get to that point: campaignd wesnothd wesmage create_images cutter exploder schema_validator and scheme_generator. You're building libraries to build all those and they all have references to unneeded code. Some more than others.
20161113 00:21:43< tad_carlucci> IF you put all the objects except those with main() into a single library you avoid the linker issues. But you end up with a few small utilities suddenly becoming very large.
20161113 00:22:43< tad_carlucci> What I did for my test toolset was the opposite. I wanted to know what was actually being pulled in. So I don't build the library and specify each individual .o by hand.
20161113 00:23:23< tad_carlucci> When I did that some of the programs exploded when I got to sdl/util because it has a reference to the entire remainder of wesnoth which isn't used.
20161113 00:24:12-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds]
20161113 00:24:42< tad_carlucci> So either delete the build target, split the source file, use function level linking, or ignore the linker error and have an un-buildable target.
20161113 00:26:09< Aginor> I'm not opposed to splitting the source file, but I am opposed to 1-function per file, and I'm also opposed to splitting the file into separate files that contain semantically related functionality
20161113 00:26:32< tad_carlucci> When I check the entire set of targets, there are 3 (iirc) which get a major reduction (20M to a few 100K) and the rest get about 50K reduction. So there's dead code somewhere everwhere but I'm not looking for that.
20161113 00:26:45< Aginor> if there's bits that are pulling in lua, or wml or whatever inside the graphical-helper system, they should be somewhere else
20161113 00:28:07< tad_carlucci> The one-function per file rule is a rule-of-thumb. And I'm not advicating going to it. But it should be a strong suggestion going forward if for no other reason than it will prevent future.
20161113 00:29:24< tad_carlucci> I'd say there's some dead code being references, but it's only about 50K per build target. Given the main target is wesnoth and it's about 20M I don't see much payback in the extreme effort it would take to find the reference to the unused code.
20161113 00:29:28< Aginor> I think that's trying to solve a social problem by technical means
20161113 00:30:18-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161113 00:31:02-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 00:31:05< Aginor> where the real problem would be that there's no clear guidelines for what's OK or not, no review process and no clear definition of responsibility of each sub-system
20161113 00:31:30< Aginor> and above all, people just doing what they want anyway ;)
20161113 00:32:46< Aginor> I agree that we have bloated binaries
20161113 00:32:49< tad_carlucci> So instead of suggesting programmers do a bit better, when it becomes a large enough problem, someone comes along and splits up a file here and there until it's not a major problem any more.
20161113 00:33:22< Aginor> tad_carlucci: isn't that exactly what you wanted to do?
20161113 00:33:37< tad_carlucci> Actually, I was surprised that it was only about 50 or 60K for most of the programs. And that could be the GUI1 stuff which vultraz is working to delete.
20161113 00:34:26< tad_carlucci> yes, that's what I wanted to do. But I felt like the push-back against splitting on file into two was too much.
20161113 00:37:12-!- louis94 [~~louis94@91.178.242.25] has joined #wesnoth-dev
20161113 00:37:13< tad_carlucci> In a similar vein: vultraz asked me to look at deleting smart_list. To do that I need to eliminate the false dependancies upon it. That means moving two classes from commonly-included files to rarely-included files; reducing the surface of the change from around 32 files to just 3.
20161113 00:38:37< Aginor> as I tried to, maybe poorly phrase it in the PR, my main objetion is that it's splitting semantically related things seemingly arbitrary into a different file. I understand that it's based on what links to which function, but it's nor very developer friendly.
20161113 00:38:53< Aginor> Also, is spending effort restructuring the code/build targets/libraries/whatevers the right thing to spend effort on right now?
20161113 00:39:31< Aginor> we should be gearing up to polish/fix bugs for 1.14 instead of having a whole lot of code churn
20161113 00:40:52< Aginor> I do however realise that fixing old bugs isn't nearly as fun/interesting as implementing the latest and greatest or making things neater. But code churn increases the chances of intruducing further bugs and regressions at a time where I think we need to fix them instead of introducing more
20161113 00:41:18< Aginor> otherwise we are simply adding more and more risk, without ever doing any risk management
20161113 00:43:31< tad_carlucci> I don't know about what's a bug or why he asked. My personal opinion is if it needs fixing, it should be fixed. I don't have a pet project and all coding is fun.
20161113 00:43:55 * Aginor puts on his project planning hat
20161113 00:44:24< Aginor> it's mid november right now, we have an arbitrary release date of february on Steam for the 1.14 release
20161113 00:44:45< Aginor> People will be away over Christmas for a 1-2 week period.
20161113 00:44:46-!- louis94 [~~louis94@91.178.242.25] has quit [Ping timeout: 252 seconds]
20161113 00:45:56< Aginor> there's at least one priority 6 bug that should be addressed, and it's not entirely small in scope
20161113 00:46:06< tad_carlucci> Honest opinion: the planned Dec release is a pipe dream. And the UI changes are still too unstable for 1.14 / Steam to hope for a late-spring release. But I'd like to be proven wrong.
20161113 00:46:10< Aginor> there's regressions in the multiplayer code and UI functionality
20161113 00:46:56< Aginor> if we're to stand any chance at all at having a release at that point, it's time to start fixing bugs/regressions instead of introducing more of them
20161113 00:47:29< Aginor> otherwise we will have an unreleasable piece of mess that will take even longer to clean up
20161113 00:48:13< Aginor> doing a GUI1 -> GUI2 conversion is a good long-term project, but it should be taken to a good-enough-for-now state and made stable
20161113 00:48:27 * tad_carlucci shrugs
20161113 00:48:52< tad_carlucci> It is what it is, now.
20161113 00:48:53< Aginor> while any further changes after that can be done as separate feature branch(es) so that they do not introduce further risk
20161113 00:49:29< Aginor> tad_carlucci: I'm talking about how to bring it from "now" to "releasable"
20161113 00:50:31< tad_carlucci> I know. I'm not the one to talk to about it. I see crashes and glitches but they're UI and I stay away from that.
20161113 00:52:39< tad_carlucci> All I know, today, is I was asked to make smart_list go away. I'm taking that as "does it need to?" as the first question and trying to find out who uses it, how, is the first question. Then once I know who and how I can ask if it really does need replacement.
20161113 00:55:51-!- louis94 [~~louis94@91.178.242.129] has joined #wesnoth-dev
20161113 01:00:20-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161113 01:00:40-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 01:04:57-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:84ef:572:4467:d547] has joined #wesnoth-dev
20161113 01:05:32-!- travis-ci [~travis-ci@ec2-54-161-205-193.compute-1.amazonaws.com] has joined #wesnoth-dev
20161113 01:05:33< travis-ci> wesnoth/wesnoth#12053 (master - cdb1640 : Celtic Minstrel): The build has errored.
20161113 01:05:33< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/175396470
20161113 01:05:33-!- travis-ci [~travis-ci@ec2-54-161-205-193.compute-1.amazonaws.com] has left #wesnoth-dev []
20161113 01:09:31-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:84ef:572:4467:d547] has quit [Ping timeout: 256 seconds]
20161113 01:14:27< Aginor> tad_carlucci: it looks rather risky to replace it :/
20161113 01:16:11< tad_carlucci> Aginor, I'm wondering if it's even broken. I will admit, at first blush, it looks a little lame but I really can't say until I know how it's used.
20161113 01:19:23< Aginor> tad_carlucci: I suspect it's working fine, but vultraz wants it to be removed because it's not a std:: or boost:: list
20161113 01:19:56< Aginor> I'd say that to remove it safely, we'd need good, passing, unit tests of the functionality before and after
20161113 01:20:13< tad_carlucci> It's possible there's a non-std:: non-boost:: thing going on. I which case, replacing it is not a good idea.
20161113 01:21:11< tad_carlucci> Actually that's why I'm reducing the dependancies. I am working on some tests and want to use the existing code as-is and test it to prove it works and I know how to use it befire I'll even consider replaceing or revising.
20161113 01:21:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161113 01:51:41< vultraz> tad_carlucci: if the removal of smart list is proving too difficult, I wouldn't object to leaving it alone. Yes, I partly asked you to remove it since it's not stl or boost, but not *because* of that. Wesnoth's codebases is full of things done in overly complicated or inefficient ways due to either a goal of "making it more simple for inexperienced coders" or actually being written by...
20161113 01:51:43< vultraz> ...inexperienced coders. I find more often than not it causes problems further down the line. In that vein, I'd like us to gradually clean up the inefficient mess in certain parts of older code. If the smart_list proves to be too big a project right now, or it serves its purpose acceptably, leave it for now.
20161113 01:51:56< vultraz> [11:48:12]	Aginor	doing a GUI1 -> GUI2 conversion is a good long-term project, but it should be taken to a good-enough-for-now state and made stable
20161113 01:52:08< vultraz> Aginor: we won't finish it in time for 1.14, sadly
20161113 01:52:18< vultraz> Aginor: but there are a few more dialogs that can be converted
20161113 01:53:38< shadowm> Are you certain that it wouldn't be worth it to finish it?
20161113 01:53:57< shadowm> You know, by delaying the release.
20161113 01:54:02< tad_carlucci> vultraz, It's not 'too difficult' it's 'inexperienced coders' throwing stuff in becuase that's where they were and not thinking about if there is a more appropriate place. I'm reserving judgement on the smart_list until I can peel away the lasters and see what's actually going on.
20161113 01:54:16< shadowm> Which is a thing that will probably happen anyway if you intend to have any hope of fixing bugs.
20161113 01:54:40< vultraz> shadowm: it's a possibility, but I'd rather not take it as a given.
20161113 01:55:27< shadowm> You should carefully weigh your options in that regard.
20161113 01:55:37< tad_carlucci> ^
20161113 01:56:40 * shadowm assumes people read the commit message wherein smart_list is introduced.
20161113 01:57:17< vultraz> Also, finishing the transition means converting the main game screen. for which we would need everyone's help, not just myself and celmin
20161113 01:58:10< shadowm> Implying a coordinated effort would be out of the question?
20161113 02:00:06< vultraz> No.
20161113 02:01:00-!- celmin|away is now known as celticminstrel
20161113 02:04:02< Aginor> redoing the main game screen also forces us to redo the editor, they are extremely tighly coupled at the moment
20161113 02:04:21< Aginor> just to point out that it's a reasonably largely scoped work item
20161113 02:05:10< vultraz> tad_carlucci: btw, i did get this comment back from AI0867 the other day: https://github.com/wesnoth/wesnoth/commit/3f584e2435eaf9a7a4b90c2dc34e18ffc7eaa943#commitcomment-19788070
20161113 02:05:19< vultraz> maybe you can understand what it means
20161113 02:05:38< vultraz> (re smart_list)
20161113 02:08:22< celticminstrel> About GUi1->GUI2, the main game interface is the primary obstacle that will (probably) prevent GUI1 from removed in 1.14.
20161113 02:08:55< celticminstrel> Yes, the editor is essentially the same as the main game screen for the purpose of this discussion.
20161113 02:09:58< celticminstrel> So vultraz, Travis is failing because the MP test never exits.
20161113 02:10:04< vultraz> yes
20161113 02:10:11< celticminstrel> Any idea why?
20161113 02:10:14< vultraz> i thought jyrki fixed that ages ago
20161113 02:10:20< tad_carlucci> first impression: the OP, long ago, didn't want to go through the trouble of implementing a full iterator when all it needed was initialization, increment, and dereference. I'm still digging into it. The only gotcha I see is adding a new element to the end of the list while iterating. Other than that, it looks like a lot of work to handle errors which should not occur.
20161113 02:10:24< celticminstrel> Did you set up the plugin context for MP wait?
20161113 02:10:29< celticminstrel> Oh, hmm.
20161113 02:10:39< celticminstrel> Is the context called MP wait?
20161113 02:11:15< vultraz> no it's called Multiplayer Join Game
20161113 02:11:25< celticminstrel> Why.
20161113 02:12:04< celticminstrel> This is an internal name, not a user-visible name.
20161113 02:12:30< vultraz> I don't know
20161113 02:12:36< vultraz> that seemed to be the format
20161113 02:13:13< celticminstrel> What was MP Staging called in GUI1?
20161113 02:13:24< vultraz> MP Connect or something
20161113 02:14:19-!- gfgtdf_ [~chatzilla@x4e368f06.dyn.telefonica.de] has joined #wesnoth-dev
20161113 02:14:20< celticminstrel> Hmm, looks like the plugin doesn't depend on that.
20161113 02:15:13< irker618> wesnoth: Celtic Minstrel wesnoth:master e0ce22880e21 / host.lua join.lua src/gui/dialogs/multiplayer/mp_join_game.cpp: MP Tests: Fix disagreement in plugin context name https://github.com/wesnoth/wesnoth/commit/e0ce22880e211567c2c278690df04392c2a5161b
20161113 02:15:51< celticminstrel> Hmm, I think it might be best to disable tests on the OSX build...
20161113 02:16:33-!- gfgtdf [~chatzilla@x4e368d0d.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20161113 02:16:43-!- gfgtdf_ is now known as gfgtdf
20161113 02:21:38-!- gfgtdf [~chatzilla@x4e368f06.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 49.0.2/20161019084923]]
20161113 02:21:41< celticminstrel> I think it'd be nice if the scons actually produced a .app on OSX (or had an additional target to package into a .app).
20161113 02:21:51< celticminstrel> But I dunno if that's worth the effort.
20161113 02:32:36-!- louis94 [~~louis94@91.178.242.129] has quit [Ping timeout: 260 seconds]
20161113 02:54:03< celticminstrel> (It's mainly just copying tons of files around.)
20161113 02:55:20-!- prkc [~prkc@46.166.190.181] has quit [Ping timeout: 265 seconds]
20161113 02:55:44< vultraz> tad_carlucci: btw, im currently trying to refactor this team_name crap in the connect engine
20161113 02:58:47< vultraz> so it seems what's going on is the connect engine kept 3 vectors
20161113 02:58:53< vultraz> all the team names
20161113 02:58:55< vultraz> all the user team names
20161113 02:59:00< vultraz> (they shouldbe the same size)
20161113 02:59:13< vultraz> and then a list of all the user team names that belong to player sides
20161113 02:59:36< celticminstrel> Doesn't it have a list of the sides anyway?
20161113 03:00:01< vultraz> yes
20161113 03:00:24< vultraz> but the individual side engines get their tn/utn members from the master list in the connect engine 
20161113 03:00:32< celticminstrel> Wouldn't that mean the first two vectors are redundant?
20161113 03:00:54< vultraz> no, those are the vectors used for the data
20161113 03:01:07< vultraz> 	const std::string team_name() const
20161113 03:01:09< vultraz> 	{
20161113 03:01:10< vultraz> 		return parent_.team_names_[team_];
20161113 03:01:12< vultraz> 	}
20161113 03:01:20< celticminstrel> Eh?
20161113 03:01:28< celticminstrel> That looks quite weird.
20161113 03:01:33< vultraz> parent_ is the connect engine
20161113 03:01:54< celticminstrel> So the side engine is what Java calls an "inner class".
20161113 03:02:01< vultraz> yeah
20161113 03:02:10< vultraz> the connect engine should probably just declare it a friend
20161113 03:02:29< celticminstrel> I think that's implicit by the fact that it's nested inside, or something. Not quite sure.
20161113 03:02:48< vultraz> it's not nested :P
20161113 03:02:52< celticminstrel> Oh okay.
20161113 03:03:04< vultraz> instead, side_engine takes a reference to connect_engine in its ctor
20161113 03:03:20< vultraz> but side_engines are only created from the connect_engine ctor 
20161113 03:03:35< vultraz> so essentially it always passes '*this' >_>
20161113 03:03:53< celticminstrel> That's kinda why I thought "inner class".
20161113 03:04:05< celticminstrel> Though technically it's not necessary for an inner class to always pass "this".
20161113 03:04:10< celticminstrel> ^take "this"
20161113 03:04:26< celticminstrel> There is something very wrong with the default resolution in 1.13.6.
20161113 03:05:05< vultraz> i need to figure out what to do with this team name stuff
20161113 03:05:13< vultraz> in some ways,what it does is make sense
20161113 03:05:27< vultraz> especially since it does additional parsing
20161113 03:05:48-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:84ef:572:4467:d547] has joined #wesnoth-dev
20161113 03:05:51< vultraz> and you get a unique list of every single team name or user team name
20161113 03:06:02< vultraz> it's slightly better than doing, like..
20161113 03:06:06< vultraz> add everything
20161113 03:06:08< vultraz> then std::sort
20161113 03:06:11< vultraz> std::unique
20161113 03:06:15< vultraz> vec.erase
20161113 03:07:41< celticminstrel> So the game appears to think it's showing at 1024x768 or something... but the window is actually 1920x1080-ish (filling the screen).
20161113 03:07:56< celticminstrel> (1916x1036 according to prefs)
20161113 03:08:45< celticminstrel> And it responds really slowly too.
20161113 03:10:03< celticminstrel> I can't even change the resolution because it keeps showing the spinning beachball and I have no idea whether it's going to respond to my clicks.
20161113 03:10:13-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:84ef:572:4467:d547] has quit [Ping timeout: 256 seconds]
20161113 03:10:17-!- prkc [~prkc@catv-89-133-39-230.catv.broadband.hu] has joined #wesnoth-dev
20161113 03:13:07< shadowm> celticminstrel: There is a bundle target in SCons that I believe is supposed to do what you want ("wesnoth-bundle = make Mac OS application bundle from game" according to --help). I rather doubt it's been maintained in the last 7 years, however.
20161113 03:13:11< celticminstrel> I guess I could've tried dragging the corners.
20161113 03:13:24< celticminstrel> shadowm: Ooh, I'll try it and see,
20161113 03:13:39< celticminstrel> So now that it's at a sane resolution, it's suddenly responsive.
20161113 03:17:10< celticminstrel> If this affects ancestral or mattsc, it should be a blocker for a 1.14 release.
20161113 03:20:48< celticminstrel> So will [sound]name= just play nothing?
20161113 03:20:54< celticminstrel> Or will it give an error?
20161113 03:25:27< celticminstrel> Well, I didn't see an error, so probably fine.
20161113 03:41:00 * tad_carlucci sighs. This is probably too much for today but why in the world are we copying the WML 'config' around for every [event]? Counting the original loaded from disk, I count at least three full copies .. two if the event never fires. 
20161113 03:42:13< tad_carlucci> Is it really possible the WML for an [event] can disappear before it fires and we still want it to fire?
20161113 03:42:23< celticminstrel> I wouldn't be surprised if there isn't a reason beyond "bad programming".
20161113 03:42:27< celticminstrel> But I'm not entirely sure.
20161113 03:42:46< celticminstrel> I think it's probably best to at least retain one copy, just to be on the safe side.
20161113 03:43:16< celticminstrel> Note that the event may potentially come from Lua rather than from the WML file loaded from disk.
20161113 03:43:23-!- travis-ci [~travis-ci@ec2-54-161-209-41.compute-1.amazonaws.com] has joined #wesnoth-dev
20161113 03:43:24< travis-ci> wesnoth/wesnoth#12054 (master - e0ce228 : Celtic Minstrel): The build has errored.
20161113 03:43:24< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/175412815
20161113 03:43:24-!- travis-ci [~travis-ci@ec2-54-161-209-41.compute-1.amazonaws.com] has left #wesnoth-dev []
20161113 03:45:19< vultraz> "error gui/layout: grid [] place: Failed to place a grid" DIOJJOIDIJKJAGHshaJKG
20161113 03:46:18< celticminstrel> So my fix did do something, but now it's idling in game waiting for not game...
20161113 03:46:58< tad_carlucci> So Lua can fire an event long after the WML [event] has been unloaded? I'd expect that unloading the WML [event] would remove the pointer to the [event] expecting the event to never fire rather than depending upon it having been copies so it can fire.
20161113 03:47:40< celticminstrel> Uh. What.
20161113 03:48:12< celticminstrel> If the event didn't fire under any circumstance, that would be a bug.
20161113 03:48:30< celticminstrel> Lua can fire events converted from Lua tables that have nothing to do with the contents of the WML file.
20161113 03:49:03< tad_carlucci> So I can load some WML, set a [event]die=. move on the another scenario and expect that if Lua wanted to fire the die from the last, it would run just fine?
20161113 03:49:20< celticminstrel> For the loaded WML file, I'd expect it to stay in memory until the scenario ends.
20161113 03:49:41< celticminstrel> I clearly said something wrong with the Lua stuff somewhere.
20161113 03:50:24< celticminstrel> Because just now you clearly asked about Lua triggering an event, whereas I was meaning to talk about Lua registering event handlers.
20161113 03:50:45< celticminstrel> Oh, come to think of it, isn't the config passed through Lua anyway when the event is registered?
20161113 03:51:01< celticminstrel> So I guess there's really no need to copy it at any point before that, if that's the case.
20161113 03:51:07< celticminstrel> Maybe toplevel events aren't, though.
20161113 03:53:19< tad_carlucci> And event is created (from someplace, dunno where, assume [event]) with a 'const config& cfg' the member is 'config cfg_' (note: not a reference) and the init is 'cfg_(cfg)' .. a copy constructor. Laster on we copy again because *this may destruct and we want to fire the event (run the WML) anyway. So we do another copy constructor.
20161113 03:54:12< tad_carlucci> Jsut code-reading what was left after I moved the smart_list cruft out of the say.
20161113 03:54:34< tad_carlucci> s/say/way/
20161113 03:58:17< celticminstrel> Kinda sounds like that could be made a reference all the way, but it's hard to be sure...
20161113 03:58:49< tad_carlucci> Given the fragility I'm seeing, a shared_ptr<> might be more wise.
20161113 03:59:35< vultraz> praise shared_ptr!
20161113 03:59:50< celticminstrel> That'd probably be safer, yeah, if we can't prove that that initial const config& will outlast everything else.
20161113 04:00:02< celticminstrel> Might still need a single copy, but I guess that's better than three.
20161113 04:00:19< celticminstrel> If the loader returned a shared_ptr you wouldn't need any copies, I guess.
20161113 04:01:00< tad_carlucci> Well, we have a manager and a factory but they don't talk to each other. Dangling points abound if someone calls the factory, destucts the manager, the fires the event.
20161113 04:01:31< tad_carlucci> *then
20161113 04:02:27< celticminstrel> I wonder if we should use std::enable_shared_from_this in places...
20161113 04:02:33< celticminstrel> (Not necessarily related to config)
20161113 04:04:29< tad_carlucci> As I said, too much to think about for tonite. I'm just trying to move the stuff around so I can see who's actually using what for the smart_list. I'm getting closer and closer to the opinion that the smart_list isn't needed at all and the owner of the smart_list should just be a std:: container of some sort instead of a class with 4 or so containers leading to the one smart_list
20161113 04:05:20< vultraz> tad_carlucci: :)
20161113 04:06:17 * celticminstrel spotted ancestral! :O
20161113 04:06:28< vultraz> ...where
20161113 04:06:31< tad_carlucci> All these pointers and shared_ptr<> and unique_ptr<> and references and weak_ptr<> and it all looks like someone wanted to do a stock off-the-shelf class-with-factory but didn't bother even looking for how to do it and just started throwing spaghetti code at the wall to see what stuch.
20161113 04:08:16< celticminstrel> Forums
20161113 04:09:27< vultraz> tad_carlucci: what worries me is if elements a are never deleted and instead just 'flagged', it could lead to memory bloat 
20161113 04:09:59< vultraz> even though gfgtdf has said it's cleared enough to not be an issue
20161113 04:11:17< tad_carlucci> What elements are you referring to? Or just in general. In general I agree it should be a concern. If you're meaning for [event] handlers, I don't see any issues, just a lot of code doing a lot of work to avoid an issue I'm not sure even is possible.
20161113 04:11:55< vultraz> the handlers
20161113 04:11:57< celticminstrel> I assume vultraz was talking about the smart_list itself.
20161113 04:12:46-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20161113 04:13:12-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161113 04:13:14< tad_carlucci> I see two uses, same form. I've refactored them from 'for(...){}'
20161113 04:15:16< tad_carlucci> to a call_for_impl( []lambda ) and now all the issues are local the the manager. I'm now trying to untangle the manager code to see if it's even possible to delete or add an [event] in the middle of the queue .. or if all this is just a way to say "fire this event, if the process added this event, don't fire it again"
20161113 04:16:42< celticminstrel> By event do you mean like... the queued_event struct/class?
20161113 04:22:44-!- Appleman1234 [~Appleman1@KD106161201055.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20161113 04:25:02-!- Appleman1234 [~Appleman1@KD106161204074.au-net.ne.jp] has joined #wesnoth-dev
20161113 04:25:03< tad_carlucci> By event I mean [event] [remove_event] and [fire_event] and things which do that in C++ or Lua.,
20161113 04:29:00< irker618> wesnoth: Celtic Minstrel wesnoth:master 8cc9e35dc0b9 / .travis.yml: Travis: Don't run tests for OSX build https://github.com/wesnoth/wesnoth/commit/8cc9e35dc0b9a5ffd9502bbd639ea8110e63472b
20161113 04:32:43< celticminstrel> Okay, so the wesnoth-bundle target misses some major copying.
20161113 04:33:09< shadowm> It was originally written back in 2008! :p
20161113 04:33:23< celticminstrel> Looks like the Frameworks folder isn't actually needed, as long as you're not planning to distribute it.
20161113 04:33:49< celticminstrel> So I'll ignore that and see if I can fix the rest of the problems.
20161113 04:35:10< celticminstrel> The target is clearly set up to create the PkgInfo file, but it's not working for some reason. I think that's a deprecated thing though, so maybe I'll just remove it.
20161113 04:35:56< celticminstrel> Though other apps seem to have it...
20161113 04:36:06< celticminstrel> I guess I'll leave it for now.
20161113 04:39:13< tad_carlucci> "not planning to distribute it" sounds like a dangerous assumption for the long-term.
20161113 04:39:18< celticminstrel> Yeah.
20161113 04:39:26< celticminstrel> But ancestral currently uses an XCode build, so...
20161113 04:42:10< celticminstrel> Frankly I'm not sure how to reliably copy the dependencies that scons resolved and ensure that they all properly reference each other.
20161113 04:43:57< celticminstrel> Though I'd hope they'd be fine if you installed them from a package manager.
20161113 04:44:11< celticminstrel> (Part of the troubles I've had in the past probably stem from the fact that I compiled Boost myself.)
20161113 04:48:00< celticminstrel> So wesnoth-bundle takes forever to copy data.
20161113 04:48:05< celticminstrel> Well, I shouldn't be too surprised though.
20161113 04:48:15< celticminstrel> It is pretty big.
20161113 04:48:30< tad_carlucci> uh yeah we established that last night
20161113 04:50:28< celticminstrel> Urgh, the info.plist needs substitutions applied to it somehow...
20161113 04:51:38< celticminstrel> I suppose I could just hard-code it...
20161113 04:52:19< celticminstrel> ie, edit the Info.plist to say "Wesnoth" instead of "${EXECUTABLE_NAME}" and "${PRODUCT_NAME}".
20161113 04:59:06-!- prkc [~prkc@catv-89-133-39-230.catv.broadband.hu] has quit [Remote host closed the connection]
20161113 05:03:05< celticminstrel> So vultraz, do you have any idea why the MP tests might not be terminating?
20161113 05:06:34-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:84ef:572:4467:d547] has joined #wesnoth-dev
20161113 05:11:29-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:84ef:572:4467:d547] has quit [Ping timeout: 256 seconds]
20161113 05:19:54-!- travis-ci [~travis-ci@ec2-54-161-209-41.compute-1.amazonaws.com] has joined #wesnoth-dev
20161113 05:19:55< travis-ci> wesnoth/wesnoth#12055 (master - 8cc9e35 : Celtic Minstrel): The build failed.
20161113 05:19:55< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/175425030
20161113 05:19:55-!- travis-ci [~travis-ci@ec2-54-161-209-41.compute-1.amazonaws.com] has left #wesnoth-dev []
20161113 05:20:28< celticminstrel> Failed, not errored, huh...
20161113 05:22:28< celticminstrel> Looks like a shell syntax error, probably.
20161113 05:22:56< celticminstrel> Line 66 of .travis.yml
20161113 05:23:08< celticminstrel> Ah, probably a missing semicolon before fi
20161113 05:23:09-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:84ef:572:4467:d547] has joined #wesnoth-dev
20161113 05:27:55-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:84ef:572:4467:d547] has quit [Ping timeout: 256 seconds]
20161113 05:45:38< irker618> wesnoth: Celtic Minstrel wesnoth:master 70326f371c0d / SConstruct: scons: Finish incomplete wesnoth-bundle target https://github.com/wesnoth/wesnoth/commit/70326f371c0d9b85be8b08fcfe7f9c7b2a4e757a
20161113 05:45:38< irker618> wesnoth: Celtic Minstrel wesnoth:master 882ded047e32 / .travis.yml: fixup! Travis: Don't run tests for OSX build https://github.com/wesnoth/wesnoth/commit/882ded047e32621eb3067bba6dbc629af9cef1dc
20161113 05:45:38< celticminstrel> scons wesnoth-bundle now produces a working .app
20161113 05:47:15< celticminstrel> Why does the .travis.yml request docker? It doesn't seem like it's used, but maybe I'm missing something.
20161113 05:47:47< shadowm> It's more like a secret password to get us Ubuntu trusty instead of precise.
20161113 05:48:06< celticminstrel> dist:trusty doesn't work?
20161113 05:48:24< shadowm> We added what Travis staff told us to add back in the day.
20161113 05:48:24-!- Shiki [~Shiki@141.39.226.226] has quit [Remote host closed the connection]
20161113 05:48:39< celticminstrel> Ah, so it might predate the dist option.
20161113 05:49:33< celticminstrel> ...
20161113 05:49:43< celticminstrel> Something's very wrong when the translations build fails.
20161113 05:50:03< celticminstrel> Blargh, so the fixup wasn't the right fix...
20161113 05:51:08< celticminstrel> Oh, I get it. The quotes were part of yml syntax, not shell syntax.
20161113 05:51:37-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has joined #wesnoth-dev
20161113 05:51:37-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has quit [Changing host]
20161113 05:51:37-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 05:52:00< irker618> wesnoth: Celtic Minstrel wesnoth:master 6247f104a3ed / .travis.yml: fixup! Travis: Don't run tests for OSX build https://github.com/wesnoth/wesnoth/commit/6247f104a3ed7be5d35959a1ab8d87bee9c6e164
20161113 05:52:29< celticminstrel> Probably better to change that conditional to "if any type of tests are enabled", but since currently the tests are always all or none, I can't be bothered.
20161113 05:53:18-!- ben_____ [d25666fe@gateway/web/freenode/ip.210.86.102.254] has joined #wesnoth-dev
20161113 05:53:48-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 245 seconds]
20161113 05:53:49-!- noy_ is now known as noy
20161113 05:55:24< ben_____> question
20161113 05:55:29< celticminstrel> I get a crash when attampting to load a map with the released bundle... looks like it might not be the same crash I'd gotten before though...
20161113 05:55:38< ben_____> any1 here know about the wesnoth site status page
20161113 05:55:47< celticminstrel> What about it?
20161113 05:55:58< ben_____> it seems to give outrageous numbers for number of players online
20161113 05:56:15< ben_____> 200 on 1.12
20161113 05:57:00< celticminstrel> Is that really outrageous?
20161113 05:57:31< ben_____> averafe number online
20161113 05:57:42< ben_____> myes that seems way higher than i observe
20161113 05:58:05< celticminstrel> Are players in games shown in the lobby list?
20161113 05:59:15< ben_____> yes
20161113 05:59:26< ben_____> sometimes the lobby has half a screen of names
20161113 05:59:40< ben_____> sometimes it goes up to like 3 screens
20161113 05:59:52< ben_____> i guess im reading the graphs way wrong
20161113 06:01:12< shadowm> loonycyborg: wesnothd-trunk is stuck at 100% CPU usage unresponsive to SIGTERM and socket commands and it seems to be preventing people from joining any server, I'm killing and restarting it.
20161113 06:01:28< shadowm> lrwxrwxrwx 1 wesnoth wesnoth 77 Nov 10 18:40 bin/wesnothd-trunk -> /home/wesnoth/builds/wesnothd-trunk-git-1.13.6-48-g3fbb356/bin/wesnothd-trunk
20161113 06:02:22< celticminstrel> 0   ???                           	vtable for __cxxabiv1::__si_class_type_info + 16
20161113 06:02:23< celticminstrel> 1   org.wesnoth.Wesnoth           	gui2::tfile_dialog::refresh_fileview(gui2::twindow&) + 210
20161113 06:02:24< celticminstrel> 2   org.wesnoth.Wesnoth           	gui2::tfile_dialog::pre_show(gui2::twindow&) + 2887
20161113 06:02:27< shadowm> loonycyborg: See /home/wesnoth/servers/trunk/logs/wesnothd.20161110-184058.1.13.6-48-g3fbb356.log , and notice that the server time right now is 06:02:08 on the 12th.
20161113 06:02:31< celticminstrel> That doesn't seem very useful though, does it?
20161113 06:02:40< celticminstrel> It's a SIGBUS...
20161113 06:02:45< shadowm> loonycyborg: Which means that it's been like this for at least 6 hours.
20161113 06:02:49-!- Appleman1234_ [~Appleman1@KD106161211149.au-net.ne.jp] has joined #wesnoth-dev
20161113 06:02:57< celticminstrel> Feels like it could be some kind of ABI compatibility?
20161113 06:03:08< celticminstrel> Maybe it'd work if I substituted libs in Frameworks... >_>
20161113 06:03:35< celticminstrel> Not going to try that right now though.
20161113 06:03:36-!- Appleman1234 [~Appleman1@KD106161204074.au-net.ne.jp] has quit [Ping timeout: 244 seconds]
20161113 06:04:16< shadowm> loonycyborg: campaignd-trunk is doing the exact same thing, also going to kill and restart it.
20161113 06:04:29< shadowm> loonycyborg: This is pretty bad.
20161113 06:06:08< shadowm> The weird thing is that wesnothd-trunk only got to run for two days or so whereas campaignd-trunk had been running fine for months.
20161113 06:06:17< celticminstrel> vultraz: Another problem with the current sliders has been pointed out.
20161113 06:06:37< shadowm> loonycyborg: Any idea if the Asio code you wrote is resilient against clock changes and that kind of thing?
20161113 06:08:20< celticminstrel> vultraz: Clicking on the bar should snap the thumb to that location - quite different from scrollbar behaviour.
20161113 06:09:49 * shadowm curses.
20161113 06:10:08< shadowm> Should've dumped core before killing.
20161113 06:10:37-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161113 06:16:54-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.]
20161113 06:21:50-!- Appleman1234_ is now known as Appleman1234
20161113 06:31:22-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161113 06:35:43-!- travis-ci [~travis-ci@ec2-54-161-205-193.compute-1.amazonaws.com] has joined #wesnoth-dev
20161113 06:35:44< travis-ci> wesnoth/wesnoth#12056 (master - 882ded0 : Celtic Minstrel): The build is still failing.
20161113 06:35:44< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/175431214
20161113 06:35:44-!- travis-ci [~travis-ci@ec2-54-161-205-193.compute-1.amazonaws.com] has left #wesnoth-dev []
20161113 06:38:19-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 06:43:10-!- Appleman1234 [~Appleman1@KD106161211149.au-net.ne.jp] has quit [Ping timeout: 256 seconds]
20161113 07:00:50-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161113 07:08:12-!- JyrkiVesterinen [~JyrkiVest@87-92-39-51.bb.dnainternet.fi] has joined #wesnoth-dev
20161113 07:11:43-!- Appleman1234 [~Appleman1@KD106161211149.au-net.ne.jp] has joined #wesnoth-dev
20161113 07:23:55< JyrkiVesterinen> 20161113 02:10:14< vultraz> i thought jyrki fixed that ages ago
20161113 07:24:05< JyrkiVesterinen> I did fix the GUI2 MP test at one point.
20161113 07:24:26< vultraz> well, i think the problem has progressed since i said that
20161113 07:24:33< vultraz> now it's stuck on 'waiting for not game'
20161113 07:24:38< JyrkiVesterinen> The test broke later when you implemented the GUI2 MP workflow.
20161113 07:25:05< JyrkiVesterinen> Fixing it has been in my todo list for a long time, but then I got distracted with the oversized chatbox bug.
20161113 07:25:27< JyrkiVesterinen> I guess I'll need to increase the priority of fixing the MP test plugin...
20161113 07:27:25< vultraz> is the fixed size widget done?
20161113 07:27:53< JyrkiVesterinen> No. The latest commits are still completely untested and cause WML unit tests to fail.
20161113 07:28:02< JyrkiVesterinen> I forgot to un-indent the header, too.
20161113 07:28:50< vultraz> blagh
20161113 07:28:53< vultraz> ok, finish that first
20161113 07:29:20< JyrkiVesterinen> All right. You may want to disable the MP test in Travis in the meantime.
20161113 07:29:46< vultraz> how do i do that?
20161113 07:29:55-!- travis-ci [~travis-ci@ec2-54-161-205-193.compute-1.amazonaws.com] has joined #wesnoth-dev
20161113 07:29:56< travis-ci> wesnoth/wesnoth#12057 (master - 6247f10 : Celtic Minstrel): The build has errored.
20161113 07:29:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/175431731
20161113 07:29:56-!- travis-ci [~travis-ci@ec2-54-161-205-193.compute-1.amazonaws.com] has left #wesnoth-dev []
20161113 07:30:52< JyrkiVesterinen> Easiest way is to change MP_TEST=true to MP_TEST=false in this line: https://github.com/wesnoth/wesnoth/blob/master/.travis.yml#L38
20161113 07:32:17< vultraz> ok ill do that
20161113 07:32:29-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161113 07:32:52-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 08:42:14< loonycyborg> shadowm: in that log just before the end it seems that some client is sending it bad data
20161113 08:52:44-!- irker618 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161113 08:57:28-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161113 09:04:06< Bonobo> Hi. Is there an option to turn off the music for the 1.13 lobby but keep it on when not in the lobby? I can't seem to find any option for it
20161113 09:09:10< loonycyborg> shadowm: I don't even see how time would matter. I don't remember doing any operations on time values.
20161113 09:11:48< loonycyborg> only use in wesnothd for a timer is for graceful shutdown
20161113 09:11:48< zookeeper> Bonobo, i guess not
20161113 09:12:05< loonycyborg> and campaignd is using steady timers
20161113 09:12:15< zookeeper> but holy crap is the lobby laggy at least with my master build. haven't tried the official 1.13.6 one.
20161113 09:13:17< zookeeper> except that seems to happen randomly
20161113 09:13:25< loonycyborg> also, it's printing time in log entries, but log code is unchanged
20161113 09:14:22< zookeeper> now it's fine. a minute ago, entering the lobby and waffling with preferences a bit made the whole thing even sluggier than the credits screen and i ended up having to kill the process.
20161113 09:16:41< loonycyborg> well, preferences are sluggish a bit for me, but nothing that can be called lag
20161113 09:19:35< Bonobo> it doesn't seem to save preferences in different tabs(eg music and general) if they're changed at the same time
20161113 09:20:41< zookeeper> yeah i've noticed that sometimes my preference changes get ignored, but i haven't been able to figure out when and why it happens
20161113 09:26:33< vultraz> ehhh???
20161113 09:54:54-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161113 10:38:47-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 10:41:10-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 256 seconds]
20161113 10:41:11-!- noy_ is now known as noy
20161113 10:42:52-!- irker779 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161113 10:42:52< irker779> wesnoth: loonycyborg wesnoth:master 43f22850878f / src/server/server.cpp: Properly delete games in custom deleter https://github.com/wesnoth/wesnoth/commit/43f22850878fe297d711a01b21566b35570236be
20161113 10:44:21-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161113 10:44:47-!- Nobun [~nobun@5.170.107.148] has joined #wesnoth-dev
20161113 10:53:52< Nobun> loonycyborg: an information for you and other core developers. If/when some features or fix required to be added to wmlxgettext, remember to write me a PM using wesnoth forum. From now on, infact, I will be have free time only on the week-ends
20161113 10:54:15< loonycyborg> hmm ok
20161113 10:54:44-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161113 10:56:29< loonycyborg> saving replays should be fixed now
20161113 10:57:00< loonycyborg> I've updated and restarted wesnoth.org server too
20161113 11:03:08-!- Appleman1234 [~Appleman1@KD106161211149.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20161113 11:08:03-!- Nobun [~nobun@5.170.107.148] has quit [Quit: Salve a tutti]
20161113 11:22:18-!- Appleman1234 [~Appleman1@KD106161211149.au-net.ne.jp] has joined #wesnoth-dev
20161113 11:22:32-!- JyrkiVesterinen [~JyrkiVest@87-92-39-51.bb.dnainternet.fi] has quit [Quit: .]
20161113 11:28:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161113 12:02:44-!- prkc [~prkc@catv-89-133-39-230.catv.broadband.hu] has joined #wesnoth-dev
20161113 12:05:04< irker779> wesnoth: Charles Dang wesnoth:master 5cce2895a14a / src/game_initialization/ (connect_engine.cpp connect_engine.hpp): Connect Engine: general cleanup https://github.com/wesnoth/wesnoth/commit/5cce2895a14a1a5c10fc8b9f4431a9a1bcec979c
20161113 12:05:07< irker779> wesnoth: Charles Dang wesnoth:master 291a7517201e / .travis.yml: Temporarily disable MP tests until they're fixed https://github.com/wesnoth/wesnoth/commit/291a7517201e9e66b3d0e8354bbcfabb0a4dafce
20161113 12:05:10< irker779> wesnoth: Charles Dang wesnoth:master 0a325797b4bd / src/ (display.cpp sdl/rect.cpp sdl/rect.hpp sdl/utils.cpp sdl/utils.hpp): Moved get_non_transparent_portion to the more appropriate file https://github.com/wesnoth/wesnoth/commit/0a325797b4bd6beb2720bd730181ce8080528c25
20161113 12:11:15-!- travis-ci [~travis-ci@ec2-54-147-188-32.compute-1.amazonaws.com] has joined #wesnoth-dev
20161113 12:11:16< travis-ci> wesnoth/wesnoth#12059 (master - 43f2285 : loonycyborg): The build has errored.
20161113 12:11:16< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/175456735
20161113 12:11:16-!- travis-ci [~travis-ci@ec2-54-147-188-32.compute-1.amazonaws.com] has left #wesnoth-dev []
20161113 12:17:28-!- _laco [~laco@static.183.80.201.138.clients.your-server.de] has quit [Remote host closed the connection]
20161113 12:19:17-!- TC01 [~quassel@london.acm.jhu.edu] has quit [Ping timeout: 248 seconds]
20161113 12:24:30-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161113 12:53:31-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161113 12:54:28-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161113 13:08:58-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161113 13:24:18-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20161113 13:28:40-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Ping timeout: 260 seconds]
20161113 13:31:21-!- travis-ci [~travis-ci@ec2-54-147-188-32.compute-1.amazonaws.com] has joined #wesnoth-dev
20161113 13:31:22< travis-ci> wesnoth/wesnoth#12061 (master - 0a32579 : Charles Dang): The build passed.
20161113 13:31:22< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/175466036
20161113 13:31:22-!- travis-ci [~travis-ci@ec2-54-147-188-32.compute-1.amazonaws.com] has left #wesnoth-dev []
20161113 13:33:04< Bonobo> the quenoth moon shyde looks like it wants to level up instead of amla and that is probably going to crash the game
20161113 13:44:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 13:51:38-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161113 13:55:43-!- Bonobo [~Bonobo@2001:44b8:254:3200:b573:68c8:5b2a:5798] has quit [Quit: Leaving]
20161113 13:57:13-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161113 14:00:10-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 14:00:15-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20161113 14:00:23< vultraz> zookeeper: ^
20161113 14:00:38-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 14:07:38-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161113 14:21:46-!- ben_____ [d25666fe@gateway/web/freenode/ip.210.86.102.254] has quit [Ping timeout: 260 seconds]
20161113 14:41:03< shadowm> loonycyborg: It was just a possibility, I haven't seen the code and it'd take me years to understand it.
20161113 14:41:21< shadowm> loonycyborg: Didn't you test against issues that may arise with malformed input?
20161113 14:41:58-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161113 14:45:06< loonycyborg> And how exactly? Using some kind of fuzzer?
20161113 14:45:23< shadowm> Does that mean no?
20161113 14:46:25< loonycyborg> iirc you gave me some perl scripts to try and I used them
20161113 14:47:04< loonycyborg> anyway I see a lot of incorrect handshake error messages in log now
20161113 14:47:21< loonycyborg> there wasn't any before
20161113 14:47:32< loonycyborg> is it some automated script perhaps?
20161113 14:48:20< loonycyborg> that doesn't properly follow WML over gzip protocol :P
20161113 14:48:28< shadowm> 11:47:50 shadowm@nanacore ~ % host 141.8.183.28
20161113 14:48:30< shadowm> 28.183.8.141.in-addr.arpa domain name pointer spider-141-8-183-28.yandex.com.
20161113 14:48:35< shadowm> The hell?
20161113 14:50:21< shadowm> So it seems to be a Yandex crawler, but this is port 15000.
20161113 14:51:53< shadowm> Í guess someone has posted a link to wesnoth.org:15000 somewhere.
20161113 15:05:03-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161113 15:05:13-!- irker779 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161113 15:21:19-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161113 15:36:00-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161113 15:51:48< celticminstrel> Shockingly, the C++14 build actually passed...
20161113 15:52:03< celticminstrel> Was it only failing because of tests all this time?
20161113 16:01:21-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161113 16:17:25 * celticminstrel hopes the MP tests can be fixed soon though.
20161113 16:20:21-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Read error: Connection reset by peer]
20161113 16:20:40-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161113 16:26:22-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161113 16:27:58-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161113 16:30:40< tad_carlucci> Ya know, if you have to #include a header names "implementation" I'd suggest that means you're about to depend upon an implementation detail and maybe you should stop and think about that. It's like driving past the "Bridge Out" sign and wondering where the road went.
20161113 16:36:35< Shiki> compiling with one core and without ccache :// forgot to change the scons options ..
20161113 16:37:07< Shiki> ah, complaining helps, just finished
20161113 16:40:43-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161113 16:43:32< celticminstrel> XD 
20161113 16:44:41< tad_carlucci> So, the question is do I fix it or do I declare the implementation detail mission-critical and leave smart_list alone?
20161113 16:45:29< celticminstrel> :| So blackspirit deleted the branch.
20161113 16:45:44< celticminstrel> tad_carlucci: Well, I don't know the context...
20161113 16:47:00< tad_carlucci> When an event fires the event handler wants to delete itself. To do that it does not say "please, mr manager, delete me" .. no it says "I know you're using a smart list and where you store your data, so I'll take care of it."
20161113 16:48:12< tad_carlucci> And THAT is not only the marriage to but the justifaction for the existance of smart_list.
20161113 16:48:36< celticminstrel> Wait, that along is the justification for its existence?
20161113 16:48:41< celticminstrel> ^alone
20161113 16:49:46< tad_carlucci> yep. since the handler reaches into the manager's internals and cahnges them the manager can't know the list it's working through just got invalidated. So we need a smart_list which does not invalidate when someone deletes from it in the middle of an interation.
20161113 16:51:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161113 16:51:14< celticminstrel> So the manager is iterating over the handlers and calling them in turn, and finds one that wants to delete itself?
20161113 16:51:52< celticminstrel> Seems like the handler could return a code indicating whether it should be deleted...
20161113 16:51:54< tad_carlucci> "MAY want to delete an unknown number of, possibly including itself"
20161113 16:52:11< celticminstrel> Ah.
20161113 16:52:22< tad_carlucci> If we could eliminate "possibly including itself" then std::list<> works fine.
20161113 16:52:36< tad_carlucci> Unfortunately, taht eliminates "first_time_only=yes"
20161113 16:52:54< celticminstrel> Right, deleting itself is in fact the most common case.
20161113 16:53:00 * tad_carlucci nods.
20161113 16:53:41< celticminstrel> I assume deleting others implies use of [event] to delete them.
20161113 16:53:50< tad_carlucci> Someone saw that problem and copied the set of handlers to a collection of weak pointers. But then someone else came along and say, no, it needs smart_list
20161113 16:53:57< tad_carlucci> [remove_event]
20161113 16:54:10< tad_carlucci> or something similar
20161113 16:54:12< celticminstrel> ...which could also potentially reference the containing event, rendering the return code method incomplete.
20161113 16:54:19 * tad_carlucci nods.
20161113 16:54:24< celticminstrel> ...there's [remove_event] too?
20161113 16:54:37< tad_carlucci> There is noting wrong with this->manager->delete(this)
20161113 16:55:07< celticminstrel> So how would the manager deal with that if it's in the middle of iteration?
20161113 16:55:13< celticminstrel> (Which presumably is normally the case.)
20161113 16:55:20< tad_carlucci> but this->manager->listmember->remove(this) is just too much
20161113 16:56:00< tad_carlucci> That's the manager's problem. It's solvable. But not if the handler reached into its guts
20161113 16:57:46< celticminstrel> Seems like something to fix.
20161113 16:58:23< tad_carlucci> Seems like something to break, too. Who knows what depends upon the handler depending upon the manager using smart_list internally?
20161113 17:00:34< tad_carlucci> I mean, it's actually fairly simple to refactor all this, shift the delete work where it belongs. And the chances are high it'll work perfectly, and make things smaller and faster. But the changes are not 100%. And while it might eliminate nasty bugs which have not been swatted, it could add some.
20161113 17:01:34< celticminstrel> I can't think of how something could depend on the handler depending on the manager's internals. (Of course that doesn't mean much...)
20161113 17:02:45< tad_carlucci> I can't imagine a C++ programmer punting, including the implementation details, adding a friend clause and not wondering if the smell was a bit too much. But that's what we have.
20161113 17:04:53< tad_carlucci> The problem is we don't know what depends upon the handler and manager, collectively, behaving as they do. There could be some seemingly unrelated code which assumes it's safe to do this, then do that, because the hander can delete a manager internal without consequence.
20161113 17:07:19< tad_carlucci> And all this coulda-shoulda thinking .. makes me realize it may also be the reason we COPY the [event] configuration instead of carry a reference to a shared copy. Maybe, somewhere, sometime, there was an event which actually DOES need to fire and run after the WML has unloaded?
20161113 17:07:56< celticminstrel> I doubt there's such an event, but there could be an event that did not come from the loaded WML.
20161113 17:08:00< tad_carlucci> Likely culprits there are end-of-scenario processing.
20161113 17:08:15< celticminstrel> Ah, I guess you do have a possible point there.
20161113 17:08:21< celticminstrel> Still doubt it though.
20161113 17:08:47< tad_carlucci> A WML-stype game event with a WML config which does not come from WML .. like Lua creates a WML config and sets an event?  I guess that's possible, too.
20161113 17:09:05< celticminstrel> Yeah.
20161113 17:10:29< celticminstrel> Also, configs passed through Lua are necessarily copied at the moment, so any nested [event] will be copied at that point.
20161113 17:10:40< celticminstrel> (Because configs are converted to native tables.)
20161113 17:11:07< celticminstrel> (Though ... maybe I'm wrong, because it might be a vconfig, which is passed as a userdata...)
20161113 17:11:58< tad_carlucci> So, do we walk away and say event handers, event managers and smart_list smell but we're not changing them? Or do we say the smell it too much and it need fixin' .. and if so, do it now and run the risk of WML events breaking when we're pushing for a stable release, or leave it for later when we branch a new development cycle.?
20161113 17:12:27< celticminstrel> I say it needs fixing, but not sure about the when.
20161113 17:12:45< celticminstrel> It doesn't seem super-high-priority, to be honest...
20161113 17:12:57< tad_carlucci> My bend is to rm -f the culprits and do it right.
20161113 17:13:19< tad_carlucci> I'm thinking that Aignor's concerns are valid and it should wait until we branch the next development cycle.
20161113 17:15:47< celticminstrel> It seems like it's not hurting anything - not causing bugs, for example.
20161113 17:15:56< celticminstrel> So I guess I lean to the same conclusion.
20161113 17:16:00 * tad_carlucci nods.
20161113 17:16:48< tad_carlucci> And I'm also thinking that doing the work will explose more smells which will need fixin' and it's only the first layer of a large, probably rotting, onion we're looking at here.
20161113 17:17:16< tad_carlucci> Or, put another way, the code is too much C and not enough C++
20161113 17:17:20< celticminstrel> Possibly.
20161113 17:18:44< tad_carlucci> Well, the handler holds a 'manager* mgr' so it depends upon its manager not going away. And that's a huge smell, to me. But fixing that .. haven't looked .. may be simple, may be a huge headache.
20161113 17:22:46< tad_carlucci> For example, I could envision use cases for moving a handler from one manager to another, making the case for a shared_ptr<>; or a manager destructing ensuring all managed handlers go away making the case for a & reference. Or even making and firing an event sans manager
20161113 17:24:28< tad_carlucci> So my thinking would be to wait until the start of a new dev cycle, and see what breaks when I delete all handler and manager code so I can tell where they're actually used.
20161113 17:25:10< tad_carlucci> Then inventory the use cases and design a clean system for those.
20161113 17:26:38< Shiki> Well, if I may say something too... Maybe your life circumstances will change by then, maybe you will not be around here anymore and that will rotten on until somebody else stumbles across it or not?
20161113 17:27:25< celticminstrel> I don't see any reason for having multiple handlers, so I'd probably go the reference route.
20161113 17:27:37< tad_carlucci> shiki That's not a problem. We use github. Make an issue or project and mark it for far-future work.
20161113 17:28:02< tad_carlucci> celticminstrel, So would I. But until we know the usages we're just guessing.
20161113 17:30:25< celticminstrel> Apparently UtBS is the only usage of [event]remove= in mainline.
20161113 17:31:06< tad_carlucci> shiki To me, the concern about life circumstances is vastly different than for most. I'm not in college and won't have to get a real job. And I'm not working and won't be changing jobs. So it's will it be gotten to before I die? And while I hope that's decades off it could be in an hour when a semi drives through the front of my house. So it's nothing I can plan on.
20161113 17:31:06< celticminstrel> But it uses it quite a lot.3
20161113 17:31:38-!- irker101 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161113 17:31:38< irker101> wesnoth: Celtic Minstrel wesnoth:master 35a581c9e739 / data/ (15 files in 3 dirs): Deprecate [event]remove= https://github.com/wesnoth/wesnoth/commit/35a581c9e73944e3126f0ded06eb09ab0da824eb
20161113 17:32:15< celticminstrel> If you're finished with the smart_list investigation, do you want to look into the failing MP tests? Or should we ask Jyrki to do that since he's worked with them before?
20161113 17:32:25< tad_carlucci> celticminstrel, I could swear I used some event removal cleaning up HttT or AToTB or DM or something. Sounds like something the mess in DM would have needed. I'd have used [remove_event] and an event id
20161113 17:32:48< celticminstrel> Ah.
20161113 17:33:08< tad_carlucci> yeah .. just like that.
20161113 17:33:10< zookeeper> wait what's going on?
20161113 17:33:13< celticminstrel> Indeed, there's [remove_event] in other places.
20161113 17:33:51< celticminstrel> Just a few, though. UtBS still dominates on the event removal (even without accounting for the fact that its scenarios are all doubled).
20161113 17:34:00 * tad_carlucci shrugs
20161113 17:34:16< tad_carlucci> Still, probably should have run that commit past zookeeper :P
20161113 17:42:48-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 17:47:43-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 17:48:26-!- gfgtdf [~chatzilla@x4e368f06.dyn.telefonica.de] has joined #wesnoth-dev
20161113 17:49:33-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161113 17:50:03-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161113 17:52:05-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 17:54:20< zookeeper> so why did you deprecate it?
20161113 17:55:43< zookeeper> because i sure don't see any reason for that so you'll have to elaborate
20161113 17:56:00< celticminstrel> Because there were two ways to do it and one was overloading a tag that does the opposite.
20161113 17:57:13-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161113 17:59:19< zookeeper> when was it that you decided to decide that it's suddenly a problem?
20161113 18:00:40< celticminstrel> Just now, I guess?
20161113 18:01:34-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161113 18:05:18 * zookeeper sighs
20161113 18:05:38< irker101> wesnoth: ln-zookeeper wesnoth:master 63b5ac21fde6 / data/lua/wml-tags.lua: Undeprecate [event]remove= https://github.com/wesnoth/wesnoth/commit/63b5ac21fde6d95d5451a32855c7f3ef33e107cb
20161113 18:05:54 * celticminstrel sighs too.
20161113 18:06:24< celticminstrel> Well, UtBS has still been completely switched over to [remove_event] though.
20161113 18:07:11< zookeeper> that's fine, unless you're planning on deprecating that next
20161113 18:07:42< celticminstrel> Considering it was listed as the intended replacement for [event[remove... why would I be planning on deprecating it?
20161113 18:10:00< zookeeper> i couldn't possibly know, but it still wouldn't surprise me
20161113 18:10:15< celticminstrel> It should surprise you. :/
20161113 18:15:57-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161113 18:16:09< gfgtdf> tad_carlucci: also note that in network games  the [scenario] is receied form te host for other clients and not part of the game config
20161113 18:16:33< gfgtdf> tad_carlucci: still i think it mkese sense to optimize [events] not to copy the wml coent when possible
20161113 18:16:55-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161113 18:17:38< gfgtdf> tad_carlucci: we ahve have a relatede item on easycoding https://wiki.wesnoth.org/NotSoEasyCoding#Don.27t_store_all_events_in_savefiles that also reuited the wm engine to know which [event]s are in the gameconfig and which not.
20161113 18:17:39< tad_carlucci> gfgtdf, More reason to put off the work until we start work in 1.15 or whatever we choose to call the next 'development' branch.
20161113 18:18:08< gfgtdf> requires*, related*, 
20161113 18:20:00< tad_carlucci> gfgtdf, ISTM that it's all fairly startightforward work, if tedious. But it's too likely to break 1.13 just weeks before 1.14/stable should appear. So, unless we want to push 1.14 out another few months, it's best to wait on fixing WML being copied and event handlers reaching into event manger's internal state.
20161113 18:22:18< tad_carlucci> At this point we have a set of features in-process. Those need to be finished. And we need to get as many visible bugs as possile from all that work swatted. We don't need to be changing internals and potentially breaking more things.
20161113 18:23:50< gfgtdf> tad_carlucci: yes it ok if you don't want todo it now.
20161113 18:25:34< tad_carlucci> gfgtdf, I don't mind looking at it. Might even do a personal branch. But if I put up a PR and it merged, that would be ill-advised.
20161113 18:27:49-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 18:43:44-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 260 seconds]
20161113 18:50:23-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 18:52:57-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 268 seconds]
20161113 18:52:57-!- noy_ is now known as noy
20161113 18:56:00-!- Shiki [~Shiki@141.39.226.226] has quit [Quit: Verlassend]
20161113 18:58:38-!- atarocch [~atarocch@178.170.139.142] has joined #wesnoth-dev
20161113 19:03:14 * zookeeper concludes that optional WML macro arguments aren't easy to implement properly
20161113 19:04:01 * celticminstrel suspects that = is actually a valid character in macro argument names at the moment.
20161113 19:04:12< DeFender1031> yeah, they wouldn't be.
20161113 19:04:57< zookeeper> i guess i might need to look into making a meta-macro mess with some of this terrain stuff...
20161113 19:05:09< DeFender1031> celticminstrel, i'd actually suggest instead that default params be in the form: #define MACRO PARAM1 PARAM2 OPTIONALPARAM{DEFAULT CRAP}
20161113 19:05:27< DeFender1031> (since {} are already reserved)
20161113 19:05:44< celticminstrel> I think that's already valid syntax too.
20161113 19:05:50< DeFender1031> but it's still not trivia to implement
20161113 19:05:58< DeFender1031> really? what would that even mean?
20161113 19:06:05< DeFender1031> trivial*
20161113 19:06:28< celticminstrel> ...unless macro substitution isn't applied to preprocessor directive lines...
20161113 19:06:50< celticminstrel> Which might be the case, I suppose...
20161113 19:06:59< DeFender1031> how COULD it be?
20161113 19:07:08-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.]
20161113 19:07:11< celticminstrel> No idea!
20161113 19:07:34-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161113 19:07:54< zookeeper> well, it might be that it wouldn't be insurmountably difficult to implement for someone who knows the preprocessor well
20161113 19:08:08-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161113 19:08:09< zookeeper> but i don't, and i was looking into the possibility of a reasonably simple hack
20161113 19:08:41-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Client Quit]
20161113 19:08:50< zookeeper> i can come up with ideas for how all the logic would work, but implementing it is another matter
20161113 19:11:37< DeFender1031> i know what you mean. I've been trying to implement a logic puzzle solver
20161113 19:13:23-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161113 19:14:40< tad_carlucci> I hate it when that happens. I'm typing along and suddenly stuff starts jumping around. So I'm frantically trying to find out what broke when the culprit announces itself with a "Meow!" .. I need a cat-proof laptop!
20161113 19:15:38< DeFender1031> tad_carlucci, two sets of input devices?
20161113 19:15:58< tad_carlucci> I was trying to say that the problem with optional macro substition is that it makes the preprocessor language ambiguous.
20161113 19:16:29< zookeeper> what do you mean?
20161113 19:16:58< tad_carlucci> DeFender1031, Yes.
20161113 19:19:12< tad_carlucci> zookeeper, Consider the form {<filename>} vs the form {<macroname>} vs {<macroname> <arg> <arg>} the question is how to know if you have too many or too few arguments or if you mean a filename with spaces in it.
20161113 19:20:16< zookeeper> well that ambiguity already exists between {<filename>} and {<macroname>}, if they just happen to be identical?
20161113 19:20:26< tad_carlucci> The preprocesses currently uses a heuristic: if it's not a macro (with arguments) try a filename
20161113 19:20:46< DeFender1031> i thought filenames had to start with ~
20161113 19:20:51< tad_carlucci> But you'd need to add "Or any other macro with the same name but more arguments"
20161113 19:21:01-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Remote host closed the connection]
20161113 19:21:10< celticminstrel> DeFender1031: No, they don't.
20161113 19:21:16< celticminstrel> Could start with . for example.
20161113 19:21:26< DeFender1031> oh...
20161113 19:21:39< DeFender1031> can they start with not a symbol?
20161113 19:21:46< celticminstrel> Not entirely sure if they're allowed to start with a letter.
20161113 19:21:49< celticminstrel> Huh?
20161113 19:21:52< tad_carlucci> DeFender1031, sure
20161113 19:21:56< celticminstrel> Oh.
20161113 19:21:58< celticminstrel> Not sure.
20161113 19:22:00< zookeeper> {english.cfg}
20161113 19:22:06< zookeeper> so yes
20161113 19:22:08< DeFender1031> and that's relative to what?
20161113 19:22:11< celticminstrel> Is that the same as {./english.cfg}?
20161113 19:22:12< DeFender1031> the current file?
20161113 19:22:26< zookeeper> possibly the root data dir
20161113 19:22:28-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161113 19:22:29< zookeeper> i dunno
20161113 19:22:33< DeFender1031> and if so, it could always be made to require ./ at the beginning to avoid the ambiguity
20161113 19:22:43< DeFender1031> zookeeper, i thought ~ was the root data dir
20161113 19:22:57< zookeeper> anyway i simply still fail to see the ambiguity problem
20161113 19:23:17< DeFender1031> come to think of it, requiring either ~ or . at the beginning would remove any ambiguity about what the path actually IS as well
20161113 19:23:40< tad_carlucci> It's not so much adding ambuguity as adding complexity to the heuristic used to resolve the existing ambiguity
20161113 19:23:49< celticminstrel> Is ~ the root data dir? I guess it's ~addons for the addons dir...
20161113 19:24:09< DeFender1031> celticminstrel, that's why i assumed that ~ was the root data dir
20161113 19:24:17< DeFender1031> though yeah, there's no / after it so i dunno
20161113 19:24:25< DeFender1031> anyway, bbiab, going afk for a bit
20161113 19:26:06< tad_carlucci> zookeeper, What would you substitute for the missing macro arguments? Would an empty replacement be OK? Would you see a difference between () or "" or not-present?
20161113 19:26:40< zookeeper> tad_carlucci, i'd substitute the default value which the macro definition declares
20161113 19:28:05< tad_carlucci> zookeeper, Ah so we'd also need to update the token parsing to scan ahead and see if there's a default and check that all following arguments also have a default.
20161113 19:28:47< zookeeper> maybe
20161113 19:28:58< tad_carlucci> zookeeper, It's 'doable' but it's gonna hit the preprocessor's source code with some big changes (almost typoed 'bug' there .. which would probably be accurate, too)
20161113 19:29:46< zookeeper> of course
20161113 19:36:12< tad_carlucci> opt-arg ::= arg '=' expression  // opt-arg-list ::= opt-arg ( [SP] opt-arg )*  // arg-list ::= arg ( [SP] arg )* ( opt-arg-list )? // The ambiguity is desiding if 'arg' introduces a required or optional argument. Only way to know is to look ahead a few tokens. Don't know if the preprocessors currentl has a token look-ahead.  IF not it's changing a LR to an LR(1) or (yuck) LR(n) which can get messy
20161113 19:37:20< zookeeper> umm.
20161113 19:37:44< zookeeper> or the macro definition simply declares the argument to be optional in a way which doesn't require lookahead.
20161113 19:37:49< zookeeper> right?
20161113 19:38:47< tad_carlucci> That solves one problem. Sounds unnatural but it could work and would eliminate look-ahead making it a much easier change.
20161113 19:39:11< zookeeper> i mean that's just something i've from the get-go assumed would be necessary anyway
20161113 19:39:25-!- atarocch [~atarocch@178.170.139.142] has quit [Ping timeout: 244 seconds]
20161113 19:41:51< tad_carlucci> #define say who what color=blue blink=no linger=yes
20161113 19:42:04< tad_carlucci> {say Delfador "Hello World" color=red}
20161113 19:42:47< tad_carlucci> {say Delfador "Hello World" blink=yes}
20161113 19:43:11< celticminstrel> I'm trying to figure out how Boost.Locale can be made to use a different message_format...
20161113 19:43:52-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161113 19:43:55< tad_carlucci> celticminstrel, To replace that pulled PR?  String replacement, regular expresion?
20161113 19:44:12-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 19:44:19< celticminstrel> No, this is about loading translations.
20161113 19:44:38-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 19:44:53< tad_carlucci> Boost punts to GNU gettext. You either replace gettext or you're looking in the wrong area
20161113 19:44:59-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 19:45:25-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 19:45:32< celticminstrel> Boost has a message_format facet which does all that work, so if there's a way to replace that...
20161113 19:45:36< celticminstrel> I dunno.
20161113 19:45:49-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 19:45:51< zookeeper> tad_carlucci, this is what i currently have in mind: https://paste.ee/p/QrtQn
20161113 19:45:53< celticminstrel> I can't see any obvious way to do so.
20161113 19:46:13-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 19:46:17< zookeeper> i had some simpler ideas in mind originally, but for various reasons i don't think they'd have worked
20161113 19:46:31< zookeeper> such as the idea of defining the defaults on the #define line
20161113 19:46:35-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 19:46:53< zookeeper> i have a very vague idea how this would work within the preprocessor code
20161113 19:47:01-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 19:47:27-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 19:47:49-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 19:48:05< tad_carlucci> I like. The only syntax issue is if you see a ?<name> and following find no ? just a name. You'll want to error on that.
20161113 19:48:10-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 19:48:37-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 19:48:57< gfgtdf> zookeeper: why putting them int the defines line not have worked ?
20161113 19:49:01-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 19:49:13< zookeeper> gfgtdf, because then you can't have multiline default values
20161113 19:49:25-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 19:49:43< zookeeper> i mean, maybe it would be possible to allow, but imagine how messy it could be in practise
20161113 19:49:48-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 19:50:11< tad_carlucci> #define MYMESSAGE SPEADER_ID MESSAGE CAPTION=".." SOUND=()   /// would work but needs look-ahead for the ='=
20161113 19:50:13-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 19:51:43< zookeeper> currently the code parses the whole argument list with one utils::split, and i rather immediately skipped the idea of having to replace that with something that would allow multiline stuff
20161113 19:51:49-!- atarocch [~atarocch@178.170.139.134] has joined #wesnoth-dev
20161113 19:53:55< tad_carlucci> Once you see ? (with or without space following) you must see a name and either end of list or another ? .. so that's not too hard
20161113 19:54:12< tad_carlucci> The question is missing or duplicated #argument 
20161113 19:54:16< tad_carlucci> need to go.
20161113 19:54:17< tad_carlucci> bbl
20161113 19:54:21-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.]
20161113 19:56:28< gfgtdf> zookeeper: do you also intend to add  named parmaeter syntax? for the case whe you fo examepl want to specify the third parameter but use the dault of the second parameter?
20161113 20:03:30-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 20:04:00< celticminstrel> Okay, so that callback that gfgtdf pointed out still requires the file to be a mo-file...
20161113 20:04:08< zookeeper> gfgtdf, yes, that's already in my pasted idea
20161113 20:04:33 * zookeeper is afk for a while
20161113 20:04:57< gfgtdf> zookeeper: oh ok so what woudl i have to do to really get the literal "SOUND=gold.ogg" as a paemter there ?
20161113 20:04:58< celticminstrel> It looks like a Boost locale is actually a vanilla instance of std::locale.
20161113 20:05:06< celticminstrel> ie, not a subclass or anything.
20161113 20:05:44< celticminstrel> So to install a custom message_format facet, you'd tell the locale generator to skip the message facet and then add it manually yourself.
20161113 20:08:10-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has joined #wesnoth-dev
20161113 20:08:10-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has quit [Changing host]
20161113 20:08:10-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161113 20:08:14< celticminstrel> Or... tell the generator to include the message facet, but then install a new one to replace it.
20161113 20:10:32-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 260 seconds]
20161113 20:10:33-!- noy_ is now known as noy
20161113 20:13:52< gfgtdf> celticminstrel: do you think we can fix the c++14 build my making it an osx build too?
20161113 20:14:42< celticminstrel> gfgtdf: Have you looked at the latest builds?
20161113 20:15:00< gfgtdf> celticminstrel: no i didnt lt me check
20161113 20:17:35< gfgtdf> hmm semes to be no error now, but not exactly sure what have fixed it
20161113 20:17:53< celticminstrel> Vultraz disabled the MP test. :/
20161113 20:18:03< celticminstrel> I'm not entirely sure if that was the sole cause, but...
20161113 20:18:10< celticminstrel> It's been passing since then.
20161113 20:22:59-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161113 20:23:17-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161113 20:23:20-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161113 20:23:42-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161113 20:24:18< gfgtdf> celticminstrel: i'm quite sure its something else, afaik it didn't even complie bafore 1.13.6
20161113 20:25:03-!- astrelyon [~astrelyon@dh207-118-38.xnet.hr] has quit [Ping timeout: 245 seconds]
20161113 20:28:22< gfgtdf> before*
20161113 20:39:25-!- astrelyon [~astrelyon@dh207-50-33.xnet.hr] has joined #wesnoth-dev
20161113 20:42:11< Aginor> in case anyone wonders, I'm fine, felt the quake but reasonably far away from me
20161113 20:43:30-!- atarocch [~atarocch@178.170.139.134] has quit [Read error: Connection reset by peer]
20161113 20:44:25< DeFender1031> Aginor, quake?
20161113 20:44:36< Aginor> a 7.5 earthquake
20161113 20:44:50< DeFender1031> holy crap
20161113 20:45:16< Aginor> https://www.geonet.org.nz/quakes/felt/severe
20161113 20:45:27< DeFender1031> yeah, just googled
20161113 20:45:52< Aginor> the 7.5 was quite noticable
20161113 20:46:04< Aginor> the smaller ones I'm not sure reached me
20161113 20:46:20< DeFender1031> eesh
20161113 20:47:15< Aginor> or I slept through them
20161113 20:47:57< celticminstrel> Good that you're fine though
20161113 20:48:05< Aginor> looking at the reports, I probably slept through them all
20161113 20:48:37< Aginor> I'm going to wellington tomorrow, that's potentially going to be more interesting with the aftershocks
20161113 20:52:50< zookeeper> gfgtdf, i'm not sure, maybe you'd have to wrap it in quotes
20161113 20:53:34< zookeeper> gfgtdf, as in, the parser would differentiate between SOUND=gold.ogg and "SOUND=gold.ogg"
20161113 20:53:50< zookeeper> or SOUND=gold.ogg and SOUND="gold.ogg"
20161113 20:53:58< zookeeper> err
20161113 20:54:04< zookeeper> "SOUND=gold.ogg" and SOUND="gold.ogg"
20161113 20:54:10< zookeeper> or whatever, you get the idea :p
20161113 20:57:15-!- atarocch [~atarocch@178.170.139.134] has joined #wesnoth-dev
20161113 20:57:32< zookeeper> Aginor, oh you're in NZ?
20161113 20:59:49< shadowm> Aginor: Oh man I thought you were in Australia instead. Is everything okay there? Power, water etc. still working normally?
20161113 20:59:52-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161113 21:02:36< Aginor> zookeeper, shadowm, yes to everything
20161113 21:02:59< Aginor> I'm fine, I'm on the north island but it's the south island that is mostly affected
20161113 21:03:20< Aginor> based on media, emergency responders are doing well and there's been very few fatalities
20161113 21:04:29< Aginor> Wellington and christchurch got a bit shaken up, but everything seems to be fine
20161113 21:04:54< Aginor> although the building I'm in is currently being assessed just to be on the safe side, it was apparently moving quite a bit (design feature)
20161113 21:05:48-!- irker101 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161113 21:07:34-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:cbd:b8e3:2b7:92ca] has joined #wesnoth-dev
20161113 21:13:25< shadowm> Okay, good to hear.
20161113 21:31:40-!- atarocch [~atarocch@178.170.139.134] has quit [Read error: Connection reset by peer]
20161113 21:36:35< gfgtdf> loonycyborg: i noticed that the 1.13.6 release still ships with both the sdl1 and the sdl2 dlls.
20161113 21:37:10< loonycyborg> I didn't remove any dlls
20161113 21:37:19< loonycyborg> there's no harm in including unused dlls
20161113 21:37:38< shadowm> No harm done, but that speaks oodles of your laziness.
20161113 21:38:13< shadowm> Except most people don't see you, they only see the project.
20161113 21:38:27< gfgtdf> vultraz: the mp connect scren crashes when i assign temans in 1.13.6 in some situations.
20161113 21:39:21< gfgtdf> vultraz: start 'path of daggers' uncheck 'user map settings' and then assign any side to 'team 4'
20161113 21:40:21-!- louis94 [~~louis94@91.178.242.129] has joined #wesnoth-dev
20161113 21:41:10< gfgtdf> vultraz: also the villagegold/support sliders are not greyed out when having initilay 'use map settings' =yes
20161113 21:41:12-!- atarocch [~atarocch@178.170.139.134] has joined #wesnoth-dev
20161113 21:41:36< gfgtdf> vultraz: same is true for the time limit sliders
20161113 21:45:22< gfgtdf> shadowm: please restart the wesnothd server for 43f22850878fe297d711a01b21566b35570236be
20161113 21:46:23< gfgtdf> shadowm: the 1.13 and trunk server i mean.
20161113 21:46:33< shadowm> Oooh.
20161113 21:46:53< shadowm> I gather louis94 didn't?
20161113 21:47:06< shadowm> Er. loonycyborg I mean. Sorry louis94 whoever you are, that was a mis-highlight.
20161113 21:47:17< celticminstrel> loonycyborg: No harm, sure, but please avoid it for future releases.
20161113 21:47:25< gfgtdf> shadowm: didn' know loonycyborg coudol do that too
20161113 21:47:45< loonycyborg> I restarted it
20161113 21:47:50< loonycyborg> after my commit
20161113 21:48:09< shadowm> lrwxrwxrwx 1 wesnoth wesnoth    75 Nov 10 18:43 wesnothd-1.13 -> /home/wesnoth/builds/wesnothd-1.13-git-1.13.6-48-g3fbb356/bin/wesnothd-1.13
20161113 21:48:15< shadowm> 18:47:48 shadowm@nanacore git:master ~/src/wesnoth % git describe 43f22850878fe297d711a01b21566b35570236be
20161113 21:48:21< shadowm> 1.13.6-138-g43f2285
20161113 21:48:25 * celticminstrel looking for the fs call to resolve a file.
20161113 21:48:25< shadowm> loonycyborg: I really don't think you did.
20161113 21:48:37< shadowm> loonycyborg: Or at the very least didn't rebuild it, which I will do now.
20161113 21:49:05< shadowm> loonycyborg: Ah, I see, you did that with the trunk server only, not the dev server (which I'm doing now).
20161113 21:49:34< celticminstrel> Hmm, get_wml_location I guess.
20161113 21:51:33< shadowm> loonycyborg, gfgtdf: Done.
20161113 21:52:17< celticminstrel> Do I need to worry about path separators...
20161113 21:53:07 * celticminstrel guesses not since WML seems to assume slash separators.
20161113 21:53:29< gfgtdf> celticminstrel: not sure what exactly you are trying to do but get_wml_location  is usullay sae, it also handles the paths fiven by {filename} ot wensot.dofile(filename)
20161113 21:53:51< celticminstrel> DeFender1031: For the record, ~ only represents the userdata dir, never the main data dir.
20161113 21:54:07< celticminstrel> Even though there's no slash after it.
20161113 21:54:27< DeFender1031> ah
20161113 21:54:40< celticminstrel> Files not beginning with ~ or . are assumed to be relative to the main data dir.
20161113 21:54:54< celticminstrel> So that's how it is.
20161113 21:56:17< DeFender1031> got it
20161113 21:56:28< DeFender1031> that actually strikes me as rather terrible.
20161113 21:56:53< DeFender1031> ideally, inclusion should be unambiguously either a macro or a file
20161113 21:57:00< celticminstrel> Yeah.
20161113 21:57:21< celticminstrel> As far as I know, macro names don't really have many restricted characters.
20161113 21:57:28< celticminstrel> (Some mainline ones use : for example)
20161113 21:57:52< DeFender1031> otherwise, one could create an add on that contains #define somecommonfile.cfg / HAHA I blew up your game!
20161113 21:57:57< celticminstrel> So if slashes are allowed too...
20161113 21:58:16< celticminstrel> Or tildes or dots even.
20161113 21:58:20< DeFender1031> now, that's not entirely a threat because people shouldn't install add ons they don't actually want, but still.
20161113 21:58:36< DeFender1031> also, it could still be fixed.
20161113 21:58:59< DeFender1031> require file includes to begin with either "/", "./", or "~"
20161113 21:59:39< DeFender1031> which would be the same as now, except that stuff from root data dir would begin with / instead of being implicit
20161113 21:59:52< celticminstrel> That'd make sense.
20161113 22:00:01< DeFender1031> and then not allow macros to begin with any of those three
20161113 22:00:09< celticminstrel> Probably would affect very few addons.
20161113 22:00:29< DeFender1031> (the rest of the name wouldn't matter... you want to #define FUN~MACRO, go ahead.)
20161113 22:00:42< DeFender1031> right.
20161113 22:01:09< DeFender1031> not saying this should definitely be done or anything, just ideally, the system ought to bbe completely unambiguous
20161113 22:03:40< DeFender1031> (which would also solve tad's issue with default parameters)
20161113 22:03:51< celticminstrel> Eh?
20161113 22:03:54< celticminstrel> It would?
20161113 22:04:49-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:cbd:b8e3:2b7:92ca] has quit [Remote host closed the connection]
20161113 22:05:06< DeFender1031> sure. if there's no ambiguity over "is this a macro call or a file include?" then there's no ambiguity of "is this a file with spaces or a macro call with this many parameters?"
20161113 22:05:40< celticminstrel> Ohhhh...
20161113 22:05:56< celticminstrel> Can the preprocessor handle files with spaces right now?
20161113 22:06:04< celticminstrel> I wouldn't be surprised if it can't.
20161113 22:06:12< DeFender1031> apparently so, according to tad's concern
20161113 22:11:17-!- atarocch [~atarocch@178.170.139.134] has quit [Ping timeout: 240 seconds]
20161113 22:21:45< Ravana_> aren't files with spaces just forbidden? I remember having to delete some to be able to upload.
20161113 22:22:03< celticminstrel> I think the addons server does forbid them.
20161113 22:22:34-!- atarocch [~atarocch@178.170.139.134] has joined #wesnoth-dev
20161113 22:28:52-!- louis94 [~~louis94@91.178.242.129] has quit [Ping timeout: 265 seconds]
20161113 22:34:09-!- atarocch [~atarocch@178.170.139.134] has quit [Read error: Connection reset by peer]
20161113 22:34:53< shadowm> IIRC substitutions of names with spaces are immediately assumed to be macro substitutions. The preprocessor is/was able to include files with spaces in their names if a directory substitution of a containing path without spaces was used.
20161113 22:35:12< shadowm> (I don't remember if this is still allowed. The add-ons server forbids any and all paths with spaces.)
20161113 22:39:18-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161113 22:39:18-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20161113 22:44:03-!- prkc [~prkc@catv-89-133-39-230.catv.broadband.hu] has quit [Quit: Leaving]
20161113 22:46:17-!- atarocch [~atarocch@178.170.139.134] has joined #wesnoth-dev
20161113 22:49:01-!- horrowind [~Icedove@ip5f5ad790.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20161113 22:53:20-!- astrelyon [~astrelyon@dh207-50-33.xnet.hr] has quit [Quit: WeeChat 1.4]
20161113 22:55:27< celticminstrel> ...why is it building liblua?
20161113 22:55:42< celticminstrel> Oh. Right, I hadn't built with XCode since the removal of linit.
20161113 22:58:36< vultraz> why has zookeeper undeprecated [event] remove=?
20161113 22:59:08< celticminstrel> Apparently he didn't agree with my deprecation in the commit before.
20161113 22:59:21< vultraz> that's my question - why
20161113 22:59:38< zookeeper> because there was no reason why it needed to be deprecated
20161113 23:00:32< tad_carlucci> zookeeper, 'need' no, 'should' probably, 'too hastily done' sure was.
20161113 23:00:55< zookeeper> i have no interest in having the same API deprecation discussion for the thousandth time
20161113 23:00:59< celticminstrel> <_<
20161113 23:01:30< tad_carlucci> DeFender1031, The problem is that done is done. A macro call and a file inclusion use the same {} marker and so it's going to be a problem
20161113 23:01:57< DeFender1031> tad_carlucci, not if what i said above is standardized upon
20161113 23:03:12< zookeeper> the only problem with macros and file inclusions using the same {} markers is that it's slightly confusing to newbies. i doubt anyone's ever actually managed to create an unintended collision unless they were doing something so stupid that it would have blown up in their face anyway one way or another
20161113 23:03:30< tad_carlucci> DeFender1031, Adding a requirement for included filesnames to have a marker can/would break too much exiting content
20161113 23:04:13< DeFender1031> not if it's done gradually
20161113 23:04:14< tad_carlucci> The point about an intentional collision is true; but it's true in other ways as well.
20161113 23:04:21< DeFender1031> true
20161113 23:05:12< vultraz> [10:00:31]	tad_carlucci	zookeeper, 'need' no, 'should' probably, 'too hastily done' sure was.
20161113 23:05:16< vultraz> pretty spot-on
20161113 23:05:41< tad_carlucci> Well, I'd prefer a more-common use such as #include "<filename>" or use <> if the name has " in it. But that's not happening either.
20161113 23:05:44< zookeeper> the best theoretical problem i can imagine would be if someone had a macro called README, and then also tried to include their README file into some help text or whatever
20161113 23:06:20< zookeeper> i can see how that might sort of maybe happen
20161113 23:13:41< gfgtdf> DeFender1031: in 1.13 wml you can use [do_command] to make units attack/move etc.
20161113 23:14:42< DeFender1031> gfgtdf, is this in response to something?
20161113 23:15:04< gfgtdf> 20161113 18:31:35< DeFender1031> you also can't call [fire_event]name=attack to make units attack each other, 
20161113 23:16:23< DeFender1031> other channel. And yes, I know. And (s)he was asking about 1.12. And it was an example.
20161113 23:17:34< gfgtdf> maybe we should add wml programming tips to the tiltescreen tips is debug mode is activated
20161113 23:18:03< gfgtdf> s/is debug/if debug 
20161113 23:18:37< vultraz> celticminstrel: how is the c++14 tests passing... it looked like a compiler error, not a tests things :|
20161113 23:18:49< vultraz> something with boost and iterator range
20161113 23:19:09< vultraz> and now it magically passes? 
20161113 23:21:35-!- Bonobo [~Bonobo@2001:44b8:254:3200:345b:e843:9fb2:5dba] has joined #wesnoth-dev
20161113 23:23:05-!- astrelyon [~astrelyon@dh207-50-33.xnet.hr] has joined #wesnoth-dev
20161113 23:23:06< celticminstrel> Dunno. Maybe it was in a deleted file?
20161113 23:23:45< vultraz> the boost errors disappeared in Split Travis dependency installation into a shell script
20161113 23:24:45< celticminstrel> Huh, that's weird.
20161113 23:24:59< vultraz> the build continued to oddly error after that
20161113 23:25:35< vultraz> up to "Removing recently-deleted GUI1 MP dialogues from VC project."
20161113 23:26:06< vultraz> it was working in "Create Engine: removed surface getters from type classes" (ie, suffering the same errors as the other tests)
20161113 23:26:36< vultraz> since 7 builds were canceled between them, I cannot say what fixed it
20161113 23:27:43< vultraz> two on travis_osx, so let's discard those..
20161113 23:28:35< vultraz> wait, i think I got it
20161113 23:28:43< vultraz> it looks like it was working fine in "Travis: Wrap entire install script in travis_wait"
20161113 23:29:12< vultraz> celticminstrel: tl'dr, you fixed it by tweaking the dependency process 
20161113 23:29:30-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161113 23:29:30< celticminstrel> Uh. Seriously?
20161113 23:29:57< celticminstrel> I didn't even really change anything... just added a separate branch for the OSX build...
20161113 23:30:12< celticminstrel> And remove all the travis_wait prefixes.
20161113 23:31:16< vultraz> you sure it didn't install a newer boost version?
20161113 23:31:26< vultraz> gfgtdf seemed to imply > 1.58 was needed
20161113 23:31:29< celticminstrel> Not sure.
20161113 23:31:53< gfgtdf> vultraz: ?
20161113 23:32:28< vultraz> gfgtdf: https://gna.org/bugs/index.php?24789
20161113 23:32:42< vultraz> "So one possible solution would be to make our build use Ububtu Xenial via docker, another solution could be to update the used boost libraries to 1.58 or later some other way. "
20161113 23:33:08< celticminstrel> Is it possible that the repos Travis is using were updated?
20161113 23:33:17< vultraz> maybe?
20161113 23:33:26< vultraz> either way im closing that bug
20161113 23:33:37< celticminstrel> Now we need to fix the MP test.+
20161113 23:34:58< vultraz> leave it to jyrki
20161113 23:35:38< celticminstrel> Speaking of Jyrki, does the new size_lock work?
20161113 23:35:55< vultraz> he said no
20161113 23:37:46-!- atarocch [~atarocch@178.170.139.134] has quit [Ping timeout: 250 seconds]
20161113 23:38:24< vultraz> tad_carlucci: so, what's the lowdown on the smart_list?
20161113 23:38:47< celticminstrel> He mentioned it earlier.
20161113 23:38:59< vultraz> I can't tell if you want to leave it, leave it for now, remove it wholly, or remove it partially and leave refactoring for later.
20161113 23:39:32< celticminstrel> Basically the reason for its existence is related to first_time_only=yes.
20161113 23:39:44< vultraz> I see
20161113 23:39:58< celticminstrel> But it's not the right way to solve that problem.
20161113 23:40:05< vultraz> I see
20161113 23:40:09< vultraz> Figures 
20161113 23:40:15< tad_carlucci> The problem is that std::list can handle deletions EXCEPT for the current item the iterator references.
20161113 23:40:19< celticminstrel> So the conclusion seems to be that we should remove it... but not until after 1.14.
20161113 23:40:25 * tad_carlucci nods.
20161113 23:40:41< gfgtdf> vultraz: iirc one of the erros there was that in the boost implementation cals make_reverse_iterator and c++14 adds a std::make_reverse_iterator which giveds comile erros becase teh cimpler doesn't know which one to call
20161113 23:40:42< tad_carlucci> It's too big a change with just a couple months until 1.14 should appear.
20161113 23:41:08< tad_carlucci> It might go smoothly but why risk a bad breakage in a core function like WML events
20161113 23:41:35< tad_carlucci> So, at present, it's "If it aint broke, don't fix it." but it
20161113 23:41:36< celticminstrel> gfgtdf: That shouldn't matter since they're in separate namespaces?
20161113 23:41:52< vultraz> tbf it's not as if we're not potentially breaking a ton of other stuff :P
20161113 23:41:55< tad_carlucci> but it's highly smelly code and very fragile and should be done, eventually
20161113 23:42:06< celticminstrel> Right, if it was causing problems it might be worth removing it right now, but since it's not currently causing any known problems, it's better to leave it.
20161113 23:42:21 * celticminstrel is currently redoing spirit_po, for reference.
20161113 23:42:35< gfgtdf> celticminstrel: hmm yes but there is also argument depndent lookup so i'm not completley sure
20161113 23:44:07< vultraz> tad_carlucci: can you smack a big TODO notice along with an explanation in handlers.hpp?
20161113 23:44:32< gfgtdf> celticminstrel: see aks this commit https://github.com/boostorg/multi_index/commit/a9c06ce5c1f35a2b2a2c96aac986a949faddbb8a
20161113 23:44:48< vultraz> gfgtdf: what is this about crashes in the mp screens?
20161113 23:45:26< gfgtdf> vultraz: to rperoduce start 'path of daggers' uncheck 'user map settings' and then assign any side to 'team 4'
20161113 23:45:55< gfgtdf> 'use map settings'
20161113 23:46:53< vultraz> hmmmmmmmmm
20161113 23:47:04< gfgtdf> did you reproduce ?
20161113 23:47:45< gfgtdf> vultraz: ^
20161113 23:48:01< vultraz> let me revert a local change 
20161113 23:49:14< tad_carlucci> vultraz, OK I guess. Actually I'm still looking at it and wondering just where to draw the line on 'fixing' the issues.
20161113 23:50:12-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161113 23:50:22< vultraz> tad_carlucci: we still have several months to go, and the possibility the release might be delayed as far a May if we want to finish the GUI2 transition (possibly). just something to consider.
20161113 23:51:13< vultraz> gfgtdf: can repro. this is odd..
20161113 23:52:16< gfgtdf> vultraz: i think its related to no side beeing in that team yet.
20161113 23:52:28< vultraz> oh?
20161113 23:52:35< gfgtdf> or no sid ebeeing that team in the initial configuration
20161113 23:52:45< gfgtdf> side beeing*
20161113 23:53:39< vultraz> ill look into it :/
20161113 23:54:29< gfgtdf> vultraz: hmm mabye it seomthign else dont really know that code
20161113 23:55:24< vultraz> hmm
20161113 23:55:27< vultraz> yes, i think you're right
20161113 23:56:17< vultraz> tree_view_node& node = team_tree_map_[side->team_name()]->add_child("side_panel", data);
20161113 23:56:21< vultraz> seems to be the problem
20161113 23:56:26< gfgtdf> vultraz: i'm using 1.13.6 release build so i cannot ive a statrace.
20161113 23:56:44< gfgtdf> right, team_tree_map_[side->team_name()] migth be null
20161113 23:56:49-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161113 23:57:22< vultraz> i guess i need to construct a new toplevel node then
20161113 23:57:25< gfgtdf> vultraz: then the solution coudl be to move this codeblock https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_staging.cpp#L100 into add_side_node
20161113 23:57:57< vultraz> ah, yes
20161113 23:58:04< vultraz> i see what you mean
20161113 23:58:05< gfgtdf> vultraz: i alos wonder whetehr we shoudl remove a toplevel node once a team becomes empty
20161113 23:59:24< vultraz> maybe
--- Log closed Mon Nov 14 00:00:19 2016