--- Log opened Tue Nov 18 00:00:05 2014
--- Day changed Tue Nov 18 2014
20141118 00:00:05< gfgtdf> iceiceice: i think unit rename are syncewsynced
20141118 00:00:11< gfgtdf> iceiceice: but
20141118 00:00:28< gfgtdf> iceiceice: still unit names are translattable
20141118 00:00:41< gfgtdf> iceiceice: so relying on tehm to be teh same on all sides is a bad idea
20141118 00:01:36< iceiceice> yeah then i guess its not a big deal if leader renames are just a casual side effect of controller change
20141118 00:04:58< gfgtdf> iceiceice: also i think [change_controller] arent saved in teh replay
20141118 00:06:49-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20141118 00:06:57< iceiceice> i don't remember if i ever thought about that
20141118 00:07:55< gfgtdf> iceiceice: so checks whether a side is ai or not are more or less never replaysafe.
20141118 00:08:53< iceiceice> unless you use synchronize choice i guess
20141118 00:09:05< gfgtdf> iceiceice: i actually whether one ever want to do things like 'if(side_is_ai_contorlled) then create_units_for_that_side()'
20141118 00:09:07< gfgtdf> iceiceice: yes
20141118 00:12:10-!- Anakonda [Anakonda@87-92-221-69.bb.dnainternet.fi] has quit [Read error: Connection reset by peer]
20141118 00:12:23< irker816> wesnoth: Chris Beck wesnoth:master c150a47e9392 / src/server/server.cpp: catch boost::bad_function_call exceptions in server command handler http://git.io/AukThg
20141118 00:18:23< shadowm> iceiceice: I'm going to ask a simple question and I hope the answer is equally simple: if I want to use Boost.filesystem on Windows I'm supposed to link in filesystem_boost.o INSTEAD of filesystem.o, right?
20141118 00:18:34< iceiceice> yes
20141118 00:18:40< shadowm> Okay.
20141118 00:18:59< shadowm> The "fun" part will be getting Boost.filesystem. ._.
20141118 00:19:59< shadowm> Well, the stuff going on in the AtS thread is making me really suspicious.
20141118 00:20:56< shadowm> Can I get another Windows user, an OS X user, and a Linux user to check whether installing AtS (no need for AtS_Music) and trying to start the campaign works?
20141118 00:21:42< iceiceice> i installed it earlier today to see if i broke lua
20141118 00:21:47< shadowm> I can't really think of a reason why Wesnoth would be allergic to terrain-graphics/trash.cfg on Windows, but shrug.
20141118 00:21:49< iceiceice> with a recent commit
20141118 00:22:13< iceiceice> since you said you were doing this "lua dialogs in prestart" shenanigans
20141118 00:22:28< iceiceice> i didnt test 1.12 though, i guess thats what your after
20141118 00:22:43< shadowm> Yes, 1.12.0 specifically.
20141118 00:23:11< iceiceice> what is the appropriate way to handle badly formed unicode. should i even log "someone gave me badly formed unicode" or is that also risky?
20141118 00:24:31< shadowm> Depends on the case, really.
20141118 00:26:49< Soliton> gfgtdf: it's now possible to create a game on the server with several billion sides, yes?
20141118 00:28:22< iceiceice> Soliton: i guess if it doesn't run out of memory
20141118 00:29:01< Soliton> does that sound like a good idea?
20141118 00:29:04< iceiceice> Soliton: is there a maximum size of a config for scenario that it will accept?
20141118 00:29:28< iceiceice> if i just make some spam config and send it to the server what will happen
20141118 00:29:53< Soliton> there's a 10MB limit somewhere IIRC.
20141118 00:30:54< iceiceice> i guess practically that's the limit on the number of sides probably
20141118 00:34:14< Soliton> i doubt that limit is enough for the server to handle such a scenario.
20141118 00:40:27-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 00:40:27< travis-ci> wesnoth/wesnoth#4814 (master - 67eb086 : Chris Beck): The build has errored.
20141118 00:40:27< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41307716
20141118 00:40:27-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 00:44:15< gfgtdf> Soliton, iceiceice i think the extra space allocated for teh sides vector is neglectable to the size of teh config
20141118 00:44:24< irker816> wesnoth: Chris Beck wesnoth:master fa54d659ef32 / src/server/ (ban.cpp server.cpp): server: catch invalid utf8 exceptions http://git.io/Zoa-MQ
20141118 00:45:15-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 00:47:29< iceiceice> gfgtdf: is there some reason that the server would frequently scan linearly across the sides vector?
20141118 00:47:44< gfgtdf> Soliton: yes there is currently no limitation besides teh sidze of tej config that i am aware of
20141118 00:47:54< iceiceice> otherwise i think you are right
20141118 00:48:41< iceiceice> i guess we can try it and see what happens
20141118 00:49:26< gfgtdf> iceiceice: can try what ?
20141118 00:49:49< iceiceice> make a scenario with 10mb of sides and see if 1.13 server craps out
20141118 00:50:40 * shadowm blinks.
20141118 00:51:06< fabi> So what changed?
20141118 00:51:12< fabi> The map format?
20141118 00:51:43< gfgtdf> fabi: no
20141118 00:51:55< fabi> oh
20141118 00:51:57< gfgtdf> fabi: map format still can onyl handle 9 starting positions
20141118 00:52:02< fabi> okay
20141118 00:52:21< fabi> But MP server is able to handle more than 9=
20141118 00:52:22< fabi> ?
20141118 00:52:30< gfgtdf> fabi: on master yes
20141118 00:52:53-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has quit [Remote host closed the connection]
20141118 00:53:56< fabi> shadowm: Our talk about the joystick preferences. Was it over? Do you feel informed now?
20141118 00:54:24< shadowm> Enough to try my hand at a preliminary design, ub t it won't happen today.
20141118 00:55:11< fabi> shadowm: My approach would be to deceide if the thing deserves an extra dialog or if the hotkey preferences one can be extended.
20141118 00:55:20< fabi> And then just clone or extend it.
20141118 00:55:36< shadowm> I lean towards the former.
20141118 00:55:39< fabi> The backend hotkey like system is already on my mind somehow.
20141118 00:57:34< gfgtdf> iceiceice: i think 10 mp of sides woudl be ~20000 sides..
20141118 00:57:41< gfgtdf> mb
20141118 00:58:01< shadowm> loonycyborg: I'm going to ask again just to make sure: 1.12.0 is using Boost.filesystem and Boost.locale, right?
20141118 00:58:16< loonycyborg> yes
20141118 00:58:25< shadowm> You are 100% sure, right?
20141118 00:59:15< shadowm> I thought using BFS would eliminate this inconsistent (but correct) usage of \ and / in paths.
20141118 00:59:42< shadowm> Okay, ****.
20141118 01:00:09< shadowm> I can confirm the issue brought up in the AtS thread, but the file exists. (???)
20141118 01:00:55< shadowm> And where is my stderr.txt?
20141118 01:02:23< shadowm> Okay, found it.
20141118 01:02:29< gfgtdf> shadowm: the bfs patch shouldn't effect the stderr.txt (yet)
20141118 01:02:39< shadowm> gfgtdf: Yes, but I think we have a problem.
20141118 01:03:27< shadowm> Hang on, let me get a test case up.
20141118 01:04:42< gfgtdf> shadowm: is it 1.12 only ?
20141118 01:06:18< shadowm> gfgtdf: Connect to the 1.12 server with 1.12.0 or 1.12.0+dev, download "Inclusion Order Test".
20141118 01:06:43< shadowm> Now let the game reload the WML config at least once (it'll do this as soon as you exit the Add-ons Manager after installing the add-on), and pastebin your stderr.txt.
20141118 01:08:29< gfgtdf> shadowm: so teh reason is teh when including folder with {} teh files in teh folder get included in teh wrong order ?
20141118 01:08:32< shadowm> Okay, this is bad.
20141118 01:08:44< shadowm> gfgtdf: Yes, _final.cfg is supposed to be included first, and it indeed does on Linux.
20141118 01:09:12< shadowm> I'm also using Boost.filesystem on Linux, so I don't know what could be causing this issue on Windows in particular.
20141118 01:09:45< shadowm> This breaks AtS because it relies on that behavior in two places.
20141118 01:09:52-!- Crendgrim [~crend@wesnoth/forum-moderator/crendgrim] has quit [Ping timeout: 245 seconds]
20141118 01:10:42< shadowm> (Behavior which is well documented. See http://wiki.wesnoth.org/PreprocessorRef#Macro_inclusions and scroll up a paragraph or two.)
20141118 01:11:13< gfgtdf> shadowm: hm maybe we change change it by unsing .generic_string() instead of .string() in filesystem::push_if_exists
20141118 01:11:49< shadowm> I can't help you with that, I don't know what's going on and I can't even build on Windows atm.
20141118 01:12:01< shadowm> That's why I wrote the test add-on.
20141118 01:12:16-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20141118 01:14:28-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 01:14:29< travis-ci> wesnoth/wesnoth#4815 (master - 1a0d9a0 : Chris Beck): The build passed.
20141118 01:14:29< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41308328
20141118 01:14:29-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 01:15:39< gfgtdf> shadowm: I can reproduce it on master with AtS, and i dont know how to debug non-self-compiled versions (1.12) so i'll test if that fixes it on master.
20141118 01:15:47< gfgtdf> shadowm: but latter, be back later
20141118 01:15:50< gfgtdf> later*
20141118 01:15:51-!- gfgtdf [~chatzilla@f050183003.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.91 [Firefox 33.1/20141106120505]]
20141118 01:16:04< shadowm> If it fixes it on master, odds it'll fix it on 1.12 too.
20141118 01:16:17< shadowm> You'll just have to build your own 1.12 build to test.
20141118 01:17:40< irker816> wesnoth: Chris Beck wesnoth:1.12 2cb85bd161d3 / src/server/player.cpp: fix an uncaught bad lexical cast exception http://git.io/MeCFrA
20141118 01:17:42< irker816> wesnoth: Chris Beck wesnoth:1.12 bb9aabd1b8b4 / src/server/ (game.cpp room_manager.cpp server.cpp): replace many lexical_cast with lexical_cast_default http://git.io/1CXgCA
20141118 01:17:44< irker816> wesnoth: Chris Beck wesnoth:1.12 8f9f3dd6f56c / src/server/server.cpp: catch boost::bad_function_call exceptions in server command handler http://git.io/mw1YbQ
20141118 01:17:46< irker816> wesnoth: Chris Beck wesnoth:1.12 d45d8ad89068 / src/server/ (ban.cpp server.cpp): backport: change server to use utf8 instead of utils unicode http://git.io/-oESvg
20141118 01:17:48< irker816> wesnoth: Chris Beck wesnoth:1.12 1bc5aa91fb8f / src/server/ (ban.cpp server.cpp): server: catch invalid utf8 exceptions http://git.io/BLOLCA
20141118 01:19:06< iceiceice> shadowm: ^
20141118 01:19:18< shadowm> What about 1.10?
20141118 01:20:37< iceiceice> that's last
20141118 01:20:42< iceiceice> shadowm: there is no 1.10 branch?
20141118 01:21:06< shadowm> What makes you think that?
20141118 01:21:18< iceiceice> error: pathspec '1.10' did not match any file(s) known to git.
20141118 01:21:31< shadowm> What command line are you using?
20141118 01:22:26< iceiceice> git checkout 1.10
20141118 01:22:40< shadowm> And why wasn't d45d8ad89068 squashed into its parent commit.
20141118 01:23:10< iceiceice> shadowm: because i wasn't thinking and i pushed it out too quickly
20141118 01:23:14< iceiceice> if its the one you are thinking of
20141118 01:23:46< shadowm> Wait isn't it utf8 on master too?
20141118 01:23:46< iceiceice> hmm wait
20141118 01:23:57< shadowm> Okay, never mind that comment, I don't understand and I'm busy.
20141118 01:24:05< shadowm> iceiceice: git fetch 1.10?
20141118 01:24:06< iceiceice> ok
20141118 01:24:26< shadowm> I mean: https://github.com/wesnoth/wesnoth/tree/1.10
20141118 01:25:12< iceiceice> so i can get to upstream/1.10
20141118 01:25:15< iceiceice> i don't have a branch there
20141118 01:25:24< iceiceice> i don't remember if i have to automatically create it?
20141118 01:25:32< iceiceice> *i have to create it, or if it happens automatically?
20141118 01:25:36< iceiceice> its just weird
20141118 01:25:52-!- Crendgrim [~crend@wesnoth/forum-moderator/crendgrim] has joined #wesnoth-dev
20141118 01:26:32< shadowm> gfgtdf: Filed https://gna.org/bugs/index.php?22967 .
20141118 01:26:53< iceiceice> ok i'm just a git noob
20141118 01:27:42< shadowm> iceiceice: `git branch -t 1.10 upstream/1.10` or something like that. This is normally done automatically for the `origin` remote.
20141118 01:28:07< iceiceice> yeah its just been so long since i did that that i forgot about it
20141118 01:28:41< iceiceice> can i use clang with 1.10 or does it blow up
20141118 01:29:00< iceiceice> i guess i will find out soon
20141118 01:29:28< iceiceice> shadowm: gah i just realized i cannot easily cherry-pick the fixes...
20141118 01:29:51< iceiceice> on 1.12 it worked like this --
20141118 01:30:11< iceiceice> aquileia and AI0867 make a bunch of new unicode related stuff, it all gets moved to utf8:: on master, (from utils::)
20141118 01:30:19< shadowm> loonycyborg, Ivanovic: https://gna.org/bugs/index.php?22967 -- gfgtdf is on it, but this is a very good reason to not use the current 1.12.0 build for Windows.
20141118 01:30:23< iceiceice> for some reason they don't fully backport this name changes on 1.12...
20141118 01:30:38< iceiceice> i found it too confusing to deal with this and it caused many merge conflicts.
20141118 01:30:46< iceiceice> so in the BFS merge, i partially backported the utf8 move
20141118 01:31:02< shadowm> Yes I know backporting stuff to 1.10 isn't trivial, I'm used to it.
20141118 01:31:21< iceiceice> alright, 1.10 is going to have to wait until after dinner
20141118 01:31:49< loonycyborg> shadowm: boost version used in release is 1.55.0
20141118 01:32:18< shadowm> loonycyborg: Could you please post that to the tracker so I don't need to triple-post myself?
20141118 01:32:41< loonycyborg> ok
20141118 01:34:14< shadowm> I think I'll look into doing the scons build and deal with the lack of an IDE/non-awkward text editor later.
20141118 01:34:21< shadowm> On Windows.
20141118 01:39:24-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 265 seconds]
20141118 01:50:27-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 01:50:27< travis-ci> wesnoth/wesnoth#4814 (master - 67eb086 : Chris Beck): The build passed.
20141118 01:50:27< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41307716
20141118 01:50:27-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 01:59:52-!- travis-ci [~travis-ci@ec2-54-83-110-19.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 01:59:52< travis-ci> wesnoth/wesnoth#4816 (master - f6bdc94 : Chris Beck): The build failed.
20141118 01:59:52< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41308699
20141118 01:59:52-!- travis-ci [~travis-ci@ec2-54-83-110-19.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 02:03:56< irker816> wesnoth: Chris Beck wesnoth:1.10 9683de3d841c / SConstruct: backport SConstruct patch 8f93e0ebb01a2cccafa45f851dd18dc660f94176 http://git.io/g5cKzA
20141118 02:03:58< irker816> wesnoth: Chris Beck wesnoth:1.10 669b9bb05e40 / SConstruct: Merge branch '1.10.7_scons_patches' into 1.10 http://git.io/ctYvbQ
20141118 02:04:00< irker816> wesnoth: Chris Beck wesnoth:1.10 3f84dc8a951a / src/server/player.cpp: fix an uncaught bad lexical cast exception http://git.io/LwBDcg
20141118 02:04:02< irker816> wesnoth: Chris Beck wesnoth:1.10 f04f7ea1ecdb / src/server/ (game.cpp room_manager.cpp server.cpp): replace many lexical_cast with lexical_cast_default http://git.io/Mi64rQ
20141118 02:04:04< irker816> wesnoth: Chris Beck wesnoth:1.10 8a687c1a0ba2 / src/server/server.cpp: catch boost::bad_function_call exceptions in server command handler http://git.io/uCvCrQ
20141118 02:04:06< irker816> wesnoth: Chris Beck wesnoth:1.10 44cf1d4a2d4c / src/server/ (ban.cpp server.cpp): server: catch invalid utf8 exceptions http://git.io/-lifAg
20141118 02:07:37< shadowm> iceiceice: What functions other than utils::lowercase in campaignd could throw an exception?
20141118 02:07:58< shadowm> I want to know because I'd rather replace them with non-throwing versions.
20141118 02:08:07< iceiceice> i don't really know
20141118 02:08:19< iceiceice> quite frankly i just assumed anything with utf8:: prefix might throw
20141118 02:08:32< iceiceice> or if its not throwing now it might start in the future
20141118 02:08:35< shadowm> But in 1.12 it's still utils, isn't it?
20141118 02:09:00< iceiceice> well in 1.12 its a little confusing, there are both the utf8:: definitions and the utils:: definitions
20141118 02:09:19< iceiceice> i backported the commits that introduced utf8:: when merging BFS
20141118 02:09:27< iceiceice> because it was too much hassle to rewrite every damn line
20141118 02:09:29< shadowm> Sigh. What's the difference between them.
20141118 02:10:02< shadowm> Oh dear gods.
20141118 02:10:07 * shadowm facekeyboards.
20141118 02:10:17< iceiceice> well one of them throws utils::invalid_utf8_exception, and one throws utf8::invalid_utf8_exception :)
20141118 02:10:49< shadowm> That's it, I'm quitting.
20141118 02:11:18< shadowm> I mean come on, why didn't you create a stub unicode.hpp with using directives instead?
20141118 02:11:58< iceiceice> it wasn't my intention to change all of 1.12 over to use whatever new version ai and aquileia came up with.
20141118 02:12:09< iceiceice> i only wanted to merge gfgtdf's BFS, whcih was based on utf8::
20141118 02:12:11< shadowm> namespace utf8 { using utils::invalid_utf8_exception; using utils::lowercase; blah blah blah; }
20141118 02:12:23< shadowm> Now we have a massive mess instead.
20141118 02:12:38< iceiceice> why don't you ask AI and aquileia why they didn't backport the utf8 namespace change
20141118 02:12:55< shadowm> Because that's beside the point.
20141118 02:12:59< iceiceice> if there was some legitimate reason, well i'm not about to change things over.
20141118 02:13:18< shadowm> I asked a question and didn't get an answer above.
20141118 02:13:32< iceiceice> you did get an answer i think,
20141118 02:13:36< shadowm> No, I did not.
20141118 02:13:40< iceiceice> i wanted to have both versions in 1.12.
20141118 02:13:49< shadowm> So what now? We'll have to handle exceptions from both namespaces everywhere?
20141118 02:13:58< iceiceice> no, the utf8:: are used in very few places.
20141118 02:14:09< iceiceice> only BFS and now the mp server.
20141118 02:14:31< iceiceice> i have no idea if they are actually different,
20141118 02:14:34< shadowm> What are the odds the number of places where it's used will grow now that backporting commits from master without hand-fixing utf8 namespace references won't result in compile-time errors?
20141118 02:14:53< iceiceice> quite frankly i have only the vaguest idea what utf8 is, i'm not prepared to evaluate the impacts of changing all the code over.
20141118 02:15:02< iceiceice> this was the most conservative change.
20141118 02:15:11< shadowm> The most conservative change was what I said.
20141118 02:15:16< iceiceice> no, it was not.
20141118 02:15:29< iceiceice> the most conservative change is the change that (1) keeps the entirety of 1.12's old code using what it was using.
20141118 02:15:33< shadowm> Did the BFS code backport involve things from utf8 that weren't present in utils?
20141118 02:15:37< iceiceice> (2) makes gfgtdf's code use the version he tested with
20141118 02:16:00< shadowm> Well, he should've tested both versions.
20141118 02:16:04< iceiceice> why?
20141118 02:16:19< shadowm> Because that's what everyone should do when backporting to a branch.
20141118 02:16:36< iceiceice> i don't see any problem with having utf8 namespace and utils namespace
20141118 02:17:16< iceiceice> if you want to try to upgrade 1.12 and get rid of the utils utf8 code, fine, i think its probably a good idea
20141118 02:17:33< shadowm> "What are the odds the number of places where it's used will grow now that backporting commits from master without hand-fixing utf8 namespace references won't result in compile-time errors?"
20141118 02:17:36< iceiceice> but frankly i was at the end of like a 48 hour backport spree
20141118 02:17:52< shadowm> "So what now? We'll have to handle exceptions from both namespaces everywhere?"
20141118 02:18:25< shadowm> Finally, this isn't even my responsibility, and I have better things to do than deal with someone else's mistake.
20141118 02:19:07< iceiceice> gfgtdf reviewed the backport and thought it was fine, i don't think we created bugs with these exceptions, because i think they were all being caught locally
20141118 02:19:18< iceiceice> certainly all those created on mp server are now caught immediately.
20141118 02:19:34< shadowm> I don't know either why the unicode rewrite was backported asymmetrically, but has anyone actually asked AI0867 and aquileia about it?
20141118 02:19:35< iceiceice> and i don't see that the situation was worse than before since none of them were *ever* caught before.
20141118 02:19:47< iceiceice> shadowm: well they are both MIA
20141118 02:20:11< shadowm> In that case I'd have definitely gone with using directives.
20141118 02:20:37< iceiceice> shadowm: there are now about 4 files that use the utf8:: namespace versions.
20141118 02:20:48< iceiceice> it will be very easy to review what exceptions are thrown, if you are really concerned about this.
20141118 02:21:11< shadowm> 23:17:33 <shadowm> "What are the odds the number of places where it's used will grow now that backporting commits from master without hand-fixing utf8 namespace references won't result in compile-time errors?"
20141118 02:21:41< iceiceice> i think those odds are minimal, becuase to use the utf8 namespace you have to specifically include src/serialization/unicode.hpp
20141118 02:23:07< shadowm> I'm going to add a local lowercase_nothrow function to campaignd.
20141118 02:23:27-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 02:23:38< iceiceice> shadowm: it might be good to add that to the utf8 header, probably we'll want it in other places
20141118 02:23:43-!- travis-ci [~travis-ci@ec2-54-234-174-54.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 02:23:43< travis-ci> wesnoth/wesnoth#4813 (master - caeaa6b : Chris Beck): The build was broken.
20141118 02:23:43< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41299164
20141118 02:23:43-!- travis-ci [~travis-ci@ec2-54-234-174-54.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 02:23:45< iceiceice> at least on master
20141118 02:25:04-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20141118 02:26:32< shadowm> I've gotten sidetracked several times to day and even recursively, hm.
20141118 02:26:48-!- Bob_The_Mighty [~chatzilla@cpc4-brig16-2-0-cust378.3-3.cable.virginm.net] has joined #wesnoth-dev
20141118 02:26:52< shadowm> I don't remember what I had planned to do.
20141118 02:28:03< shadowm> Okay, so 1) preprocessor context pop bug; 2) rebuild servers; 3) fix campaignds; 4) rebuild campaignds. I think.
20141118 02:29:12< vultraz> Are we re-tagging once #1 is fixed?
20141118 02:35:10-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 02:35:10< travis-ci> wesnoth/wesnoth#4817 (master - c150a47 : Chris Beck): The build passed.
20141118 02:35:10< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41310010
20141118 02:35:10-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 02:36:06-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20141118 02:37:51-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 02:38:04< shadowm> vultraz: What? No.
20141118 02:38:18< shadowm> Retagging is forbiden.
20141118 02:38:36< shadowm> Furthermore, it's a minor issue that can wait for 1.12.1.
20141118 02:39:39< shadowm> ancestral: So you can build on OS X now, right? Any chances you could try to reproduce https://gna.org/bugs/?22967 there?
20141118 02:40:04< shadowm> (Preferably using 1.12, although it's supposedly not a branch-specific issue.)
20141118 02:40:29< ancestral> I conked out early last night and didn’t try iceiceice’s latest script, but yes, otherwise I’ve been able to build
20141118 02:40:59< shadowm> You could try with your last build too if it's less than a week old.
20141118 02:41:04< ancestral> attached add-on archive?
20141118 02:41:20< ancestral> Is it attached somewhere else?
20141118 02:41:29< shadowm> Whoops. Fixed now.
20141118 02:42:03< ancestral> Yeah, I will test this tonight, but it’s gonna be late
20141118 02:43:07< ancestral> stderr outputs to a file, yes?
20141118 02:43:21< shadowm> I can't answer that question for OS X.
20141118 02:44:37< ancestral> In UNIX, if I open the app ./wesnoth
20141118 02:45:17< ancestral> Does stderr output to the currently running shell, or do I have to specify that with a syntax
20141118 02:45:23< shadowm> I've never used UNIX, only Unix-like OSes like Debian GNU/Linux and FreeBSD. By default stderr is output to the controlling terminal.
20141118 02:45:56< vultraz> shadowm: are you referring to the _final.cfg thing or something else
20141118 02:46:02< vultraz> That doesn't seem minor
20141118 02:46:18-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 02:46:18< travis-ci> wesnoth/wesnoth#4816 (master - f6bdc94 : Chris Beck): The build passed.
20141118 02:46:18< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41308699
20141118 02:46:18-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 02:46:29< ancestral> Well, OS X is a FreeBSD descendent, so that probably bodes well
20141118 02:46:39< shadowm> (Shell != terminal. The shell usually doesn't have any business to do with it unless you specifically want to redirect a child process' stderr to a file or something.)
20141118 02:47:07< ancestral> I’m not up to speed with the terminologies
20141118 02:47:17< shadowm> vultraz: No, I'm referring to the preprocessor context restore bug.
20141118 02:47:39< ancestral> But I learns!
20141118 02:47:43< ancestral> [sic]
20141118 02:47:55< shadowm> vultraz: Compare https://gna.org/bugs/?22967 and https://gna.org/bugs/?22962 .
20141118 02:48:02< ancestral> Alright, back to work
20141118 02:48:03-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20141118 02:55:33-!- kex [~kex@78.157.29.160] has quit [Remote host closed the connection]
20141118 02:57:28-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20141118 02:58:45-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 02:58:48-!- un214 [~un214@2602:306:cccf:af99:56a0:50ff:fe57:101d] has joined #wesnoth-dev
20141118 03:03:43-!- gfgtdf [~chatzilla@d110090.adsl.hansenet.de] has joined #wesnoth-dev
20141118 03:09:57< shadowm> Okay, preprocessor_streambuf defaults to the wesnoth textdomain, good.
20141118 03:10:39-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 03:10:39< travis-ci> wesnoth/wesnoth#4818 (master - fa54d65 : Chris Beck): The build passed.
20141118 03:10:39< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41312444
20141118 03:10:39-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 03:11:42< gfgtdf> iceiceice, shadowm: changing to generic_string() seems to fix teh problem for me
20141118 03:11:58< shadowm> And a pp context will pop the textdomain correctly on destruction.
20141118 03:12:21< shadowm> So I should focus on exactly how context management gets involved with nested macro inclusions.
20141118 03:12:34< shadowm> gfgtdf: Could you explain the change to me?
20141118 03:14:29< gfgtdf> shadowm: here https://github.com/wesnoth/wesnoth/blob/master/src/filesystem_boost.cpp#L393 "/_final.cfg" but on windows it might be "\_final.cfg"
20141118 03:14:53< shadowm> Oh god.
20141118 03:15:02< gfgtdf> shadowm: we fiy tis by storing teh stings in teh generic format (posix format) in files
20141118 03:15:07< gfgtdf> fix*
20141118 03:15:16< shadowm> Is there anything else that may make that incorrect assumption?
20141118 03:15:29< gfgtdf> shadowm: that can be done by using path.generic_string() instead of .string()
20141118 03:15:30< shadowm> _initial.cfg, it seems.
20141118 03:16:05< gfgtdf> shadowm: in this line https://github.com/wesnoth/wesnoth/blob/master/src/filesystem_boost.cpp#L194 and after
20141118 03:16:19< shadowm> Does that mean generic_string() returns a version with '/' as path separator regardless of platform?
20141118 03:16:21< gfgtdf> shadowm: i actuyl wonder whether we shoudl change all ocurrances of .string() with generic_string
20141118 03:16:25-!- travis-ci [~travis-ci@ec2-54-83-110-19.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 03:16:25< travis-ci> wesnoth/wesnoth#4820 (1.10 - 44cf1d4 : Chris Beck): The build is still failing.
20141118 03:16:25< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41318200
20141118 03:16:25-!- travis-ci [~travis-ci@ec2-54-83-110-19.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 03:16:30< gfgtdf> shadowm: yes
20141118 03:18:13< shadowm> Okay, I don't want to read the full Boost.filesystem documentation, but that sounds like a good idea?
20141118 03:18:47< shadowm> gfgtdf: Also note that I'll be forcing loonycyborg and/or Ivanovic to make a 1.12.0a build/release with whatever patch(es) come out of this before Saturday.
20141118 03:19:29< shadowm> I guess not Ivanovic, since the issue does seem to be Windows-specific in that case. All our other officially-supported platforms use / as delimiter.
20141118 03:19:32< gfgtdf> shadowm: unless there is some unknown code somewhere in a #ifwin32 that asusmes \ seperators (which i dont think) than id' using generic_string() is always a good idea
20141118 03:20:39< gfgtdf> shadowm: also windows can in most cases handle '/' sperared paths
20141118 03:22:11< shadowm> Grepping for '\\', '\134', and '\x5C' should reveal all code that explicitly uses backslashes for anything.
20141118 03:22:59< shadowm> Including a heap of irrelevant matches.
20141118 03:24:18< gfgtdf> shadowm: well i really dont think anyone would use such cryptic forms in the cppcodes
20141118 03:25:02< shadowm> This is Wesnoth. It never hurts to make sure.
20141118 03:25:27< shadowm> Plus '\\' is actually the only valid form in C++ without C++11 raw string literals.
20141118 03:25:44< shadowm> Aside from the numeric escapes, that is.
20141118 03:26:34< shadowm> My experience with Wesnoth thus far has been "if there is a way people will do XYZ wrong, they will do it".
20141118 03:28:04< gfgtdf> shadowm: i found \ in preprocessor::get_file_code but idk what it does and some in string_utils
20141118 03:28:34< shadowm> It's part of a call to utils::escape().
20141118 03:29:29< shadowm> Eh.
20141118 03:29:33< gfgtdf> shadowm: hm i think its unrelated to windows paths
20141118 03:29:47< shadowm> It's actually related but not relevant.
20141118 03:29:49< gfgtdf> shadowm: also soem odducrances in filesystem.cpp of cource but those are not important here
20141118 03:34:25< shadowm> I'm going to think aloud for a while here about a completely different bug.
20141118 03:35:15< shadowm> Okay, so brace substitution requires the preprocessor to keep reading the brace block before going back and performing the actual substitution at the start.
20141118 03:35:31< shadowm> I had forgotten this entirely obvious fact.
20141118 03:36:53< shadowm> A #define's intrinsic textdomain is the #define context's textdomain.
20141118 03:37:48< gfgtdf> shadowm: abot utf8:: and utils:: : y there are function in utf8:: but not in utils, especialy the unicode_cast function. We do no only use that functon in the filesystem_boost fiel but also in most places were we use the windows api. (for example when we copy text to the cipboard)
20141118 03:38:03< shadowm> { inititates the MACRO_CHUNK token.
20141118 03:38:15< shadowm> Er, MACRO_SPACE.
20141118 03:39:51< shadowm> gfgtdf: Is that 'y' a 'yes'?
20141118 03:39:58< gfgtdf> shadowm: y
20141118 03:40:07< shadowm> Grrrrrrrrrrrr.
20141118 03:40:14< gfgtdf> yes
20141118 03:40:56< shadowm> Okay, so those functions missing in 1.12's utils depended upon code that wasn't present in 1.12 either?
20141118 03:42:24< gfgtdf> shadowm: in this commit i changes unicode_cast in master https://github.com/wesnoth/wesnoth/commit/cdd35a4bead50ffbdfb96cc384c42d48f877b2ed
20141118 03:42:46< shadowm> By the way, I'm really surprised the unicode functions backport asymmetry wasn't explained in commit messages or the original PR(s). Right now it feels like I can't trust anything cross-branch.
20141118 03:43:03< shadowm> I'm seriously afraid of doing any bug fixes atm.
20141118 03:44:47< gfgtdf> shadowm: we can try deleting the unicode.cpp/hpp files in 1.12 any only keep the unicode_cast.hpp, and some other headers in that folder
20141118 03:44:55< gfgtdf> s/any/and
20141118 03:45:47< shadowm> But wasn't the argument for all this specifically that you (or iceiceice?) didn't trust that the 1.12 and master versions of the unicode stuff had the same semantics and behavior.
20141118 03:45:50-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20141118 03:45:51< irker816> wesnoth: gfgtdf wesnoth:master 009403ae3ee5 / src/server/game.cpp: simplify wesnothd::game::change_controller http://git.io/Wn19cA
20141118 03:45:53< irker816> wesnoth: gfgtdf wesnoth:master 115c2a7985ae / src/filesystem_boost.cpp: use generic_string() http://git.io/G9QxpQ
20141118 03:45:58< shadowm> *and/or iceiceice
20141118 03:46:15< iceiceice> shadowm: i decided to do this not gfgtdf,
20141118 03:46:22< iceiceice> but we discussed in channel afterwards.
20141118 03:46:32< gfgtdf> shadowm: i thouvght it wasnt that bad
20141118 03:46:35< gfgtdf> thought*
20141118 03:46:40< iceiceice> shadowm: we tested the crap out of this
20141118 03:46:44< shadowm> Okay, so to recap:
20141118 03:46:55< iceiceice> the only places that were using utf8:: after htis commit were filessystem and gettext
20141118 03:47:06< shadowm> 1) What were the arguments against dropping the utils functions in favor of the utf8 functions from master?
20141118 03:47:25< gfgtdf> iceiceice: it even possible that NONE of teh files uses a utf8:: function
20141118 03:47:28< shadowm> 2) What were the arguments against ignoring the utf8 functions from master and aliasing their utils counterparts using the 'using' directive instead?
20141118 03:47:28< iceiceice> if you really think a utf8::invalid_utf8_exception can crash 1.12.0, idk i would want to see some evidence
20141118 03:47:31< gfgtdf> in 1.12
20141118 03:47:44< gfgtdf> iceiceice: i call unicode_cast here not an utf8:: function
20141118 03:47:44< iceiceice> shadowm: if you want to redo it, be my guest!
20141118 03:47:46< shadowm> These are the two points I want explained concisely and correctly.
20141118 03:48:06< iceiceice> the arguments were, this is what made the most sense to me, and it also tested out just fine.
20141118 03:48:12< shadowm> The arguments for 1 or 2?
20141118 03:48:18-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20141118 03:48:56< iceiceice> shadowm: i already explained both of these to you an hour ago
20141118 03:49:41< iceiceice> quite frankly i'm pretty annoyed at your remark from earlier "that's it i quit" as though i had no idea that i was now introducing a second exception type
20141118 03:49:43< shadowm> I believe every programmer ever understands that code duplication is both, so I'm surprised we went with that third option.
20141118 03:49:58< shadowm> *bad
20141118 03:50:11< iceiceice> shadowm: well feature-freeze and RC candidate changes things DRAMATICALLY
20141118 03:50:21< shadowm> Especially for an *API*.
20141118 03:50:38< iceiceice> what?
20141118 03:50:51< shadowm> lowercase() and friends are part of our project-wide API.
20141118 03:50:58< iceiceice> what is the big issue! there's two differnet namespaces, with two different implementations.
20141118 03:51:34< iceiceice> if someone makes a commit to master to master now where they start including new files like src/serialization/unicode, and usign the utf8 namespace, and wondering gee why is it throwing different exceptions...
20141118 03:51:38< iceiceice> i think they are a bad programmer
20141118 03:51:53< iceiceice> if you really want to be super safe,
20141118 03:51:55< iceiceice> then by all means,
20141118 03:52:04< iceiceice> go to exceptions.hpp, define invalid_utf8_exception there,
20141118 03:52:12< iceiceice> and in both of the utils/ utf8 namespsaces typedef to that.
20141118 03:52:23< iceiceice> but if you are acting liek i introduced a major bug...
20141118 03:52:28< iceiceice> i think you have to defend that point of view.
20141118 03:52:29< shadowm> The big issue is that there are two identical APIs (meaning different class/types to handle) and code may use either.
20141118 03:52:50< iceiceice> afaik they are not identical
20141118 03:52:57< iceiceice> i have no idea of the nature of the differences,
20141118 03:53:09< iceiceice> i did the work of backporting this,
20141118 03:53:17< iceiceice> because if i hadn't done it, we just wouldn't have been able to release,
20141118 03:53:28< shadowm> This means that later down the road we might end up with a situation where one exception type goes unhandled because an unchecked call to the second API ended up backported to code that previously used the first API.
20141118 03:53:32< iceiceice> because the executable would simply be broken on windows.
20141118 03:53:45< shadowm> Yes, and I understand that, good job.
20141118 03:54:05< shadowm> I'm not questioning the importance of your contributions. That'd be stupid.
20141118 03:54:46< shadowm> I'm merely questioning the decision of getting us stuck with this potential maintainability and reliability mess for code *unrelated* to the work in question.
20141118 03:54:49< iceiceice> ok. i feel like we are all same team here
20141118 03:55:19< iceiceice> yeah, i realized that the situation was not ideal, and we did also discuss backporting the other of 8680's commits that made the utf8 namespace
20141118 03:55:27< iceiceice> but i didn't want to do that at the time
20141118 03:55:27< shadowm> And by 'stuck' I do mean stuck, because there is pretty much no way I'd go and undo it.
20141118 03:55:31-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 03:56:56< shadowm> </tangent>
20141118 03:57:30< iceiceice> ok well, i see two options (1) the hard way, actually eliminate utils namespace on 1.12, and test this change. (2) leave the two versions, but typedef the exceptions to be the same
20141118 03:57:45< shadowm> I need to focus on #22962 if I want to have any spare time for non-Wesnoth things this week.
20141118 03:58:14< shadowm> (2) sounds good if the exception types are internally identical.
20141118 03:58:33< iceiceice> i'm willing to do (2), because you have raised a valid point
20141118 03:58:41< iceiceice> i'm not comfortable to try to do (1)
20141118 03:58:48-!- Ivanovic_ [~ivanovic@frnk-5f74d2a7.pool.mediaWays.net] has joined #wesnoth-dev
20141118 03:58:50< shadowm> (1) is something I'd personally not do at this point because it may cause even more problems depending on the exact differences between API 1 and API 2.
20141118 03:59:20< gfgtdf> we still have 3) eleiminate the utf8:: fucntion in 1.12
20141118 03:59:39< shadowm> But that's just a rephrased version of (1)?
20141118 03:59:43< gfgtdf> ass addition to 2 that is
20141118 03:59:48< gfgtdf> as*
20141118 04:00:19< mattsc> shadowm: I’ve been awat most of the day (and not read up on the logs yet) and still don’t have time right now.  Just quickly: do you need/want me to test #22967 in OS X?
20141118 04:00:20< shadowm> Okay, not rephrased, just with the same risks and smaller impact.
20141118 04:00:25< mattsc> I could do so in about an hour or so.
20141118 04:00:38-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 258 seconds]
20141118 04:00:42-!- Ivanovic_ is now known as Ivanovic
20141118 04:00:44< shadowm> mattsc: Yes, if you have time, otherwise there's no hurry as the underlying code suggests it's Windows-specific.
20141118 04:00:57< gfgtdf> shadowm: i think teh boost filesystem patch uses none of the utf8:: functions that are also in utils::
20141118 04:01:01< mattsc> shadowm: okay, I’ll try later.
20141118 04:01:02< iceiceice> gfgtdf: if you think that will work that's probably a good option
20141118 04:02:40< gfgtdf> i uses some typedefs and teh unicode_cast function
20141118 04:03:53< gfgtdf> so what we coudl do is: 1. typdef the exception 2. partly undo d45d8ad8906 3. remove unicode.cpp form compilation and see whether it complies.
20141118 04:05:26< shadowm> Okay, cool, brace substitutions behave differently depending on the preprocessor nesting level. < 40 allows file substitutions, anything larger than that only allows macro substitutions, and the nesting maximum (inclusive) is 99.
20141118 04:05:35-!- _8680_ [~8680@2002:4404:712c:0:c585:216f:f1e0:a635] has joined #wesnoth-dev
20141118 04:05:59< shadowm> Such nice undocumented behavior.
20141118 04:06:07< _8680_> I don’t recall having introduced a `utf8` namespace.
20141118 04:06:14-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 04:07:06< shadowm> And there is a "slow path" concept involved.
20141118 04:08:02< shadowm> It seems to correspond to macro nesting.
20141118 04:08:23< shadowm> 20141118 01:08:18 debug config: substituting (slow) macro A
20141118 04:08:48< shadowm> (Also why does half of the preprocessor stuff use a different log domain than the other half.)
20141118 04:09:59< shadowm> It's at this point that I'm wondering exactly how exception-safe the parser and preprocessor are, because these unnerving new and delete operators can be seen all over the place.
20141118 04:10:07< iceiceice> _8680_: i backported this commit at some point:
20141118 04:10:08< iceiceice> https://github.com/wesnoth/wesnoth/commit/c86b905fef5dcd71abf1c91517f663b5cfdef0e5
20141118 04:10:22< iceiceice> because it was a prerequesite for other utf8 related commits i seemed to need to backport
20141118 04:10:53< iceiceice> sorry...
20141118 04:11:02< iceiceice> i got you guys confused
20141118 04:11:08< shadowm> But yes, what happens when you throw an istream's backing buffer at an ostream using operator<<?
20141118 04:11:57< iceiceice> this was the commit i actually needed: https://github.com/wesnoth/wesnoth/commit/121f9bc9a997b071dc75b2268bc1ac921087f220
20141118 04:12:20< shadowm> I guess it's an unformatted write into the ostream.
20141118 04:13:13< shadowm> Write everything left in the istream's backing buffer into the ostream.
20141118 04:14:57< shadowm> I wonder why the idiom isn't to pass the istream to operator<< though?
20141118 04:19:22< shadowm> Eh.
20141118 04:20:27< shadowm> preprocessor_data is a subclass of preprocessor, preprocessor can't force the initial textdomain but preprocessor_data can.
20141118 04:22:44< shadowm> I've written a number of textdomain probes and now "textdomain" no longer sounds like a word to me.
20141118 04:23:54< shadowm> file contexts start with the default textdomain (wesnoth).
20141118 04:24:03-!- gfgtdf [~chatzilla@d110090.adsl.hansenet.de] has quit [Quit: ChatZilla 0.9.91 [Firefox 33.1/20141106120505]]
20141118 04:26:41< shadowm> Okay, so nested inclusions reset the textdomain to wesnoth via the preprocessor destructor.
20141118 04:27:38< shadowm> > NESTED SUBSTITUTION TEXTDOMAIN: YYYYYYYY
20141118 04:27:40< shadowm> > BEGIN PREPROCESSOR CONTEXT WITH TEXTDOMAIN wesnoth
20141118 04:27:56< shadowm> Okay, so the current textdomain is forgotten right before calling the constructor?
20141118 04:28:38< shadowm> Oh, right, we instantiate a new preprocessor streambuf between the branching point and the new preprocessor_data instantiation.
20141118 04:29:00< shadowm> The preprocessor_streambuf defaults to wesnoth.
20141118 04:29:26< shadowm> There are no obvious means to tell it to use a different textdomain.
20141118 04:30:05< shadowm> What the hell.
20141118 04:30:40< shadowm> preprocessor_streambuf has no friends or subclasses and textdomain_ is private and left untouched after the constructor.
20141118 04:31:18< shadowm> Oh wait, never mind, it does have several friends.
20141118 04:31:54< shadowm> Yes, target_ is the streambuf.
20141118 04:32:33< shadowm> Okay.
20141118 04:32:41< shadowm> I think there's an oversight here.
20141118 04:33:11< shadowm> A new preprocessor_streambuf is needed for nested macro substitutions but not for non-nested substitutions (not sure why, must research).
20141118 04:33:43< shadowm> For non-nested substitutions, the current preprocessor_streambuf is used, which means the latest textdomain binding is used during substitution.
20141118 04:33:52< shadowm> That is the substitution context's textdomain.
20141118 04:34:14< shadowm> For nested substitutions, and also file substitutions, a new preprocessor_streambuf is instantiated with the default textdomain.
20141118 04:34:53< shadowm> But for nested substitutions, a preprocessor_data context is instantiated using that streambuf and the previous streambuf's textdomain is passed to the constructor.
20141118 04:35:52< shadowm> In the constructor: if (t.textdomain_ != domain) { /* set the streambuf textdomain to what we were asked to use */ }
20141118 04:36:17< shadowm> But that doesn't happen, so.
20141118 04:36:52< shadowm> Oh wait, no, it does happen. I'm reading my own probes wrong.
20141118 04:37:17< shadowm> :O
20141118 04:37:23< shadowm> That's it.
20141118 04:37:37< shadowm> preprocessor_data's constructor does that, yes, good.
20141118 04:37:59< shadowm> But that's after preprocessor's constructor has recorded the previous textdomain to emit a <FE>textdomain directive on destruction.
20141118 04:38:08< shadowm> And the previous textdomain is wrong!
20141118 04:38:55< shadowm> There is no way to inform it of the previous (initial) textdomain  being overruled.
20141118 04:39:09< shadowm> So that confirms the design oversight theory.
20141118 04:40:50< iceiceice> yeah so it seems like its pretty hard for the preprocessor to both do what it is supposed to do, and get all the strings right
20141118 04:41:38< shadowm> The biggest question here is why several classes must keep track of the textdomain history and agree on it so that Bad Things™ don't happen.
20141118 04:42:06< iceiceice> right, because if i have #define A B C D\\{{B} {C} {D} {C}}\\#enddef or something like this,
20141118 04:42:07< shadowm> First there is preprocessor_streambuf, which is an accessory to preprocessor.
20141118 04:42:17< iceiceice> liek a macro that takes other macros as arguments,
20141118 04:42:19< shadowm> Then there is preprocessor.
20141118 04:42:34< iceiceice> the only way that i get the right answer is if i start changing text immediately to construct the new macro arguments
20141118 04:42:58< iceiceice> and i should not be doing things like, trying to fully expand arguments B C D to the macro as soon as i see it
20141118 04:43:02< shadowm> And then preprocessor_data (subclass AND friend of preprocessor) may manipulate preprocessor's state.
20141118 04:43:17< iceiceice> so by the time i get down to individual translatable strings, things have moved around a lot.
20141118 04:43:33< iceiceice> but in fact if i want to find what the right text domain is, that is easiest when the strings have not been oved.
20141118 04:43:35< iceiceice> *moved
20141118 04:43:38< shadowm> (I sure don't think 'protected' hadn't been invented already at the time this was written.)
20141118 04:44:08-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141118 04:44:16< shadowm> Wait no, preprocessor_data isn't preprocessor's friend. It's preprocessor_streambuf's friend.
20141118 04:44:41-!- travis-ci [~travis-ci@ec2-54-234-174-54.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 04:44:41< travis-ci> gfgtdf/wesnoth-old#381 (p - 1bc5aa9 : Chris Beck): The build passed.
20141118 04:44:41< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/41325674
20141118 04:44:41-!- travis-ci [~travis-ci@ec2-54-234-174-54.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 04:44:51< iceiceice> shadowm: here's a crazy idea, but let me throw it out anyways,
20141118 04:44:53< shadowm> (Because why would we use public in *private *classes that are so closely intimate with each other right?)
20141118 04:45:13< iceiceice> maybe what should happen is that there shoudl be a "first pass" that marks each string with the correct text domain
20141118 04:45:26< iceiceice> and the preprocessor should run after that, and forget entirely about text domains.
20141118 04:46:01< iceiceice> it might significantly simplify the preprocessor
20141118 04:46:07< shadowm> The preprocessor doesn't currently mark strings, except when it does.
20141118 04:46:25< shadowm> (It marks substitution arguments that may or may not be strings, instead.)
20141118 04:46:49< shadowm> (They may also be a singular or plural number of strings or not-strings.)
20141118 04:48:08< shadowm> Okay, so in order to fix #22962 we can either redesign the whole thing to do away with the nonsensical intimate class relationships (no-no for 1.12),
20141118 04:48:22-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 240 seconds]
20141118 04:48:44< shadowm> ... or just add yet another hack to allow preprocessor_data to overrule its base class' memory of the initial textdomain, which is really the easiest solution, even if it glorifies a bogus design.
20141118 04:49:08< shadowm> So I'll just go that last option for now.
20141118 04:49:56< shadowm> Later down the road I'll see if I can somehow tidy up the weird dependency web (not tree) without rewriting the whole thing.
20141118 04:51:36< mattsc> shadowm: all I need to do to test #22967 is to get the attached test add_on and start Wesnoth?  Doing that, the only error message I get in OS X is that it does not have an _info.cfg.
20141118 04:51:48< mattsc> Well, that’s a warning, not an error, I guess.
20141118 04:51:51< iceiceice> if it's really this hard for you to read, and no one who originally made it is around anymore, maybe we should just chuck the whole thing in 1.14
20141118 04:52:02< iceiceice> and rewrite it
20141118 04:52:18< shadowm> The person who wrote it isn't returning, yeah.
20141118 04:52:48< shadowm> mattsc: That can't be right, you should see two #warning messages in the output.
20141118 04:56:07< shadowm> iceiceice: But half of my difficulty reading this is because I don't do iostreams. (The other half is preprocessor_streambuf being everyone's friend and being abused as such.)
20141118 04:57:04< mattsc> shadowm: just by starting Wesnoth?
20141118 04:57:09< shadowm> preprocessor_streambuf's friends: preprocessor -> preprocessor_data -> preprocessor_file (preprocessor and its base classes)
20141118 04:57:34< shadowm> *Everyone* manipulates preprocessor_streambuf directly.
20141118 04:58:12< shadowm> mattsc: Yes.
20141118 04:58:46< shadowm> My fix works. \o/
20141118 04:58:56< shadowm> I mean the textdomain fix.
20141118 04:59:07< mattsc> shadowm: well, I don’t.  :(  http://pastebin.com/sWSsp0Hc
20141118 04:59:38< mattsc> except for the usual CFContext warnings, that’s all there is
20141118 04:59:44< shadowm> mattsc: You didn't install it right then.
20141118 04:59:56< mattsc> shadowm: yay on the textdomain fix !
20141118 05:01:04< shadowm> mattsc: http://pastebin.com/3mkG0PkS
20141118 05:01:37-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 05:01:39< shadowm> Lines 13 and 14 are the expected output when your build/platform is immune to #22967.
20141118 05:01:55< shadowm> Also, in that specific order.
20141118 05:03:54< mattsc> shadowm: well, I don’t.  
20141118 05:04:13< mattsc> And I looked at the add-on, it looks correctly installed to me
20141118 05:04:25< shadowm> :|
20141118 05:04:31< mattsc> the files in it each contain a line starting with ‘#warning'
20141118 05:04:41< shadowm> mattsc: Could you try to install AtS instead and see if you can start E1S1?
20141118 05:05:02< mattsc> Do I have to have certain debug message level set for that to work?
20141118 05:05:05-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 05:05:11< shadowm> The default.
20141118 05:05:54< mattsc> Upgrading to AtS 0.9.11
20141118 05:09:13-!- Bob_The_Mighty [~chatzilla@cpc4-brig16-2-0-cust378.3-3.cable.virginm.net] has quit [Quit: ChatZilla 0.9.91 [Firefox 33.1/20141106120505]]
20141118 05:09:21< mattsc> shadowm: “Yrunry: Night falls, and the scouts …”
20141118 05:09:24-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 05:09:24< travis-ci> gfgtdf/wesnoth-old#383 (p - 3d61b92 : gfgtdf): The build passed.
20141118 05:09:24< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/41325863
20141118 05:09:24-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 05:09:30< mattsc> Seems to be working.
20141118 05:09:35< shadowm> Okay, what the crap then?
20141118 05:10:05< shadowm> The #warning diagnostic isn't platform-specific or anything, so there's no reason you shouldn't be seeing it at the start.
20141118 05:10:12< mattsc> Yeah, I’ll try to figure that out some other time.  (So a line starting with #warning should give you a warning message>)
20141118 05:10:25< mattsc> okay, so there you answere that already  :)
20141118 05:10:29-!- un214 [~un214@2602:306:cccf:af99:56a0:50ff:fe57:101d] has quit [Remote host closed the connection]
20141118 05:10:35< shadowm> http://wiki.wesnoth.org/PreprocessorRef#.23warning
20141118 05:11:08< mattsc> right …   (at some time I knew that!)
20141118 05:11:19< mattsc> Well, I’m a bit short on time today, I’ll check out what’s going on there some other time.
20141118 05:11:26< shadowm> I really doubt it, because #error and #warning went undocumented for at least one stable series.
20141118 05:11:57< shadowm> IIRC #warning also used to use the error log severity.
20141118 05:12:42< shadowm> Okay, so now I have to evaluate the regression potential of my textdomain nesting fix.
20141118 05:12:50< mattsc> Hmm ...
20141118 05:12:58< shadowm> Also, I'm really surprised nobody ever came across this bug before.
20141118 05:13:46< mattsc> shadowm: I just changed the #warnings to #errors and then one of them (abc.cfg) shows up.
20141118 05:14:05< shadowm> That makes sense, because the preprocessor will stop on the first error.
20141118 05:14:15< shadowm> No matter whether it's a legitimate error or an injected #error.
20141118 05:14:19< mattsc> yes, that’s what I expected
20141118 05:14:34< mattsc> so that means that the order on OS X is as it should, I take it?
20141118 05:14:53< shadowm> Yeah, most likely. (The alternative is that _final.cfg is ignored, but hopefully that's not the case.)
20141118 05:15:16< mattsc> Nope.
20141118 05:15:18< shadowm> Still I want to know what the deal with the missing #warnings are.
20141118 05:15:29< shadowm> is.
20141118 05:15:39< mattsc> If I change abc.cfg back to #warning and leave _final.cfg as error, then the latter shows up.
20141118 05:15:47-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 05:15:47< travis-ci> gfgtdf/wesnoth-old#382 (p - 9368782 : gfgtdf): The build passed.
20141118 05:15:47< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/41325805
20141118 05:15:47-!- travis-ci [~travis-ci@ec2-23-20-198-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 05:15:56< mattsc> Yes, me too.  I’ll check that out sometime in the next couple days.
20141118 05:16:41< shadowm> Anyway, it seems the preprocessor's handling of textdomains may have changed slightly between 1.8 and 1.10 leading to #22962 appearing at some point in between.
20141118 05:18:39-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141118 05:18:55< shadowm> Actually, no, it looks like a trivial <FE>textdomain emit optimization.
20141118 05:19:18< shadowm> So #22962 may also apply to 1.8.
20141118 05:24:17< shadowm> And possibly 1.6 and 1.4 and 1.2.
20141118 05:43:01-!- AI0867 [~ai@wesnoth/developer/ai0867] has quit [Ping timeout: 255 seconds]
20141118 05:43:09-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 264 seconds]
20141118 05:45:27-!- AI0867 [~ai@wesnoth/developer/ai0867] has joined #wesnoth-dev
20141118 06:00:14< shadowm> Okay, there is a problem with my fix.
20141118 06:01:08< shadowm> It'd cause the macro's own textdomain to persist at the end of its substitution.
20141118 06:02:00< shadowm> I guess instead I should allow the preprocessor_streambuf's initial textdomain to be set.
20141118 06:02:59< shadowm> Oh dear gods I don't even need to do that because I'm in preprocessor_streambuf's private friend.
20141118 06:03:28< shadowm> I can just go and clobber textdomain_ myself without a middleman.
20141118 06:04:57< shadowm> Alternatively, have the caller emit the required trailing <FE>textdomain, but that would result in two consecutive trailing <FE>textdomain.
20141118 06:05:48< shadowm> Okay, look, #textdomain already goes and overwrite the streambuf's textdomain by design, so I can just do that.
20141118 06:06:28< shadowm> Don't overthink this awful design, it's awful and that's all that matters. Just keep pushing awfully-designed code to fix its quirks until we can have a better design.
20141118 06:11:50-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Bye for now]
20141118 06:16:30< shadowm> Yes, that's more like it.
20141118 06:16:34< shadowm> Excellent.
20141118 06:19:53-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20141118 06:25:05< shadowm> Wesnoth 1.0 compiles in 16 seconds here with -j8.
20141118 06:25:22< shadowm> We've come a long way since then, haven't we.
20141118 06:32:38-!- cib0 [~cib@p5DD20FCC.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 06:41:35< shadowm> Okay, turns out the bug was introduced at some point after 1.8.
20141118 06:52:19-!- timotei_ [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 255 seconds]
20141118 06:53:05-!- cib0 [~cib@p5DD20FCC.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
20141118 06:54:14-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20141118 07:01:12-!- Sulfur [~Miranda@p5B327A55.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 07:06:31-!- Ivanovic [~ivanovic@frnk-5f74d2a7.pool.mediaWays.net] has quit [Changing host]
20141118 07:06:31-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20141118 07:07:18-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20141118 07:18:15< shadowm> Hm.
20141118 07:18:27< shadowm> There seems to be an unexpected optimization-like side-effect.
20141118 07:18:43< vultraz> Always good
20141118 07:18:58< shadowm> Not really.
20141118 07:19:41-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141118 07:20:05< shadowm> There is a small chance I might have failed to account for something and screwed up textdomain bindings further.
20141118 07:20:38-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141118 07:20:44-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Client Quit]
20141118 07:22:09< shadowm> Actually, the "optimization" disappears entirely after the parser pass.
20141118 07:22:27< shadowm> It also seems my campaign wasn't affected by this bug.
20141118 07:23:23< shadowm> Ought to check Swamplings instead, I guess.
20141118 07:25:22-!- {V} [~V@72-69-ftth.on.nl] has quit [Ping timeout: 250 seconds]
20141118 07:26:00-!- {V} [~V@72-69-ftth.on.nl] has joined #wesnoth-dev
20141118 07:26:17< shadowm> Swamplings looks properly fixed.
20141118 07:26:29< shadowm> And now, let's check every single mainline campaign.
20141118 07:33:11-!- {V} [~V@72-69-ftth.on.nl] has quit [Read error: Connection reset by peer]
20141118 07:33:34-!- {V} [~V@72-69-ftth.on.nl] has joined #wesnoth-dev
20141118 07:41:27< shadowm> DW, DM, DiD, EI, HttT, LoW, Liberty, SoF, THoT, TRoW, TSG are affected by the bug but present no functional differences with and without the fix.
20141118 07:41:57< shadowm> SotBE presents a suspicious functional difference before and after the fix.
20141118 07:42:49< shadowm> UtBS breaks with the fix.
20141118 07:45:10< shadowm> SotBE breaks with the fix too.
20141118 07:45:17< shadowm> God dammit
20141118 07:45:41< shadowm> Wait.
20141118 07:45:48< zookeeper> fixing dugi's textdomain weirdness, i presume?
20141118 07:45:50< shadowm> I'm looking at the diff upside down.
20141118 07:46:03< shadowm> Blargh I have to do everything again.
20141118 07:47:04-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141118 07:48:59< shadowm> DW, DM, DiD, EI, HttT, LoW, Liberty, SoF, THoT, TRoW, TSG affected by the bug but no functional changes after the fix, yeah, right.
20141118 07:49:59< shadowm> SotBE is affected by the bug in a really weird way, and benefits from the fix.
20141118 07:50:40< shadowm> The macro substitution on scenarios/07_The_Desert_of_Death.cfg:36 (TURNS_RUN_OUT) was getting the SotBE textdomain instead of the wesnoth textdomain.
20141118 07:52:56< shadowm> UtBS was affected by the bug and benefits from the fix.
20141118 07:54:26< shadowm> The affected portions were the ENEMY_ATTACK and ALLY_REINFORCEMENTS macros in data/campaigns/Under_the_Burning_Suns/scenarios/05_A_Subterranean_Struggle.cfg (line 1749 onwards).
20141118 07:55:21< shadowm> And since I got the diff order right this time, no, this fix is in fact an anti-optimization.
20141118 07:56:28< shadowm> Namely, it increases <FE>line/<FE>textdomain footprint by a negligible amount.
20141118 07:57:04< shadowm> But again, that goes away on parse+reserialization.
20141118 08:01:05< shadowm> data/ and data/core/ were affected by the bug but present no functional changes after the fix.
20141118 08:01:36< shadowm> Same goes for data/multiplayer/.
20141118 08:01:37-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 08:15:01< shadowm> Ah never mind the SotBE thing, it's line 439 instead of 36.
20141118 08:15:21< shadowm> That explains it.
20141118 08:15:35< shadowm> Probably.
20141118 08:15:49< shadowm> I don't know why it wasn't popping the wesnoth textdomain before.
20141118 08:20:31< irker816> wesnoth: Ignacio R. Morelle wesnoth:master c43f9883d639 / changelog src/serialization/preprocessor.cpp: preproc: Inherit parent textdomain on slowpath macro substitution (bug #22962) http://git.io/3jtqow
20141118 08:20:34< irker816> wesnoth: Ignacio R. Morelle wesnoth:1.12 1482e8d5fbb3 / changelog src/serialization/preprocessor.cpp: preproc: Inherit parent textdomain on slowpath macro substitution (bug #22962) http://git.io/TSQZvg
20141118 08:21:57-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141118 08:23:52< shadowm> This was the most involved fix I've ever committed and it's a one-liner.
20141118 08:25:01< zookeeper> what's slowpath macro substitution? O.o
20141118 08:25:29< zookeeper> oh, right, there's a long description there...
20141118 08:26:22-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 240 seconds]
20141118 08:26:49< zookeeper> cool
20141118 08:27:14 * zookeeper has a truckload of cookies delivered to shadowm's house
20141118 08:28:50< shadowm> vultraz: Re your question, loonycyborg must upload a patched build once gfgtdf commits the fix for #22967 to 1.12. It's not your responsibility.
20141118 08:29:17< shadowm> gfgtdf: Why isn't the fix for #22967 in 1.12 yet?
20141118 08:30:14< shadowm> Ivanovic: Do you agree with sticking to the unpatched 1.12.0 for all platforms but Windows? (The bug in question: <https://gna.org/bugs/?22967>)
20141118 08:30:36< shadowm> Ivanovic: And yes, this is really important to have settled before the announcement.
20141118 08:30:42-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Ping timeout: 245 seconds]
20141118 08:34:22< shadowm> (Also, I'll take it to the mailing list if you don't respond during the following 48 hours based on my previous experience with poking you about #20815.)
20141118 08:51:55-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 272 seconds]
20141118 09:29:15-!- Anakonda [Anakonda@87-92-239-131.bb.dnainternet.fi] has joined #wesnoth-dev
20141118 09:57:44-!- shadowm_laptop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141118 10:01:53-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141118 10:10:42-!- Ardonik [~user@adsl-75-28-101-131.dsl.irvnca.sbcglobal.net] has joined #wesnoth-dev
20141118 10:16:54-!- Sulfur [~Miranda@p5B327A55.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141118 10:44:31-!- cib0 [~cib@132.231.178.20] has joined #wesnoth-dev
20141118 10:58:28-!- cib0 [~cib@132.231.178.20] has quit [Ping timeout: 244 seconds]
20141118 11:03:17-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 11:03:55< AI0867> shadowm: I'll get on the coverity stuff later today (as soon as I have constant power for my laptop)
20141118 11:06:49-!- Sulfur [~Miranda@p5B327A55.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 11:15:32< AI0867> shadowm, iceiceice: I think it was backported asymmetrically to minimize 1.12 disruption
20141118 11:19:25-!- fabi [~quassel@p20030051AA25B9937902E16C92A30767.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 11:19:25-!- fabi [~quassel@p20030051AA25B9937902E16C92A30767.dip0.t-ipconnect.de] has quit [Changing host]
20141118 11:19:25-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 11:20:39-!- irker816 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20141118 11:23:52-!- sachith500 [~kvirc@112.134.143.189] has joined #wesnoth-dev
20141118 11:25:49-!- shadowm_laptop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 272 seconds]
20141118 11:33:24-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 11:33:45-!- fabi [~quassel@p20030051AA25B9937902E16C92A30767.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 11:33:45-!- fabi [~quassel@p20030051AA25B9937902E16C92A30767.dip0.t-ipconnect.de] has quit [Changing host]
20141118 11:33:45-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 11:42:52-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 11:44:03-!- fabi [~quassel@p20030051AA25B993E5A008D860900A5E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 11:44:03-!- fabi [~quassel@p20030051AA25B993E5A008D860900A5E.dip0.t-ipconnect.de] has quit [Changing host]
20141118 11:44:03-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 11:44:13-!- fendrin [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 11:46:21-!- fendrin [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 11:47:46-!- boucman_2 [~jrosen@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20141118 11:51:12-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 255 seconds]
20141118 11:59:37-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20141118 12:02:27-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 12:03:33-!- cib0 [~cib@132.231.178.66] has joined #wesnoth-dev
20141118 12:03:39-!- fabi [~quassel@p20030051AA25B9932C3CC24AC5E6DEE1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 12:03:39-!- fabi [~quassel@p20030051AA25B9932C3CC24AC5E6DEE1.dip0.t-ipconnect.de] has quit [Changing host]
20141118 12:03:39-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 12:05:11-!- lipkab [~the_new_l@2001:738:5404:192:9e4e:36ff:fe7c:534c] has joined #wesnoth-dev
20141118 12:09:07-!- sachith500 [~kvirc@112.134.143.189] has quit [Read error: Connection reset by peer]
20141118 12:09:24-!- sachith500 [~kvirc@112.134.143.189] has joined #wesnoth-dev
20141118 12:14:02-!- Sulfur [~Miranda@p5B327A55.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141118 12:14:26-!- sachith500 [~kvirc@112.134.143.189] has quit [Read error: Connection reset by peer]
20141118 12:15:04-!- boucman_2 is now known as boucman_work
20141118 12:15:14-!- boucman_work [~jrosen@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Changing host]
20141118 12:15:14-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141118 12:16:03-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20141118 12:20:08-!- cib0 [~cib@132.231.178.66] has quit [Read error: Connection reset by peer]
20141118 12:26:20-!- lipkab [~the_new_l@2001:738:5404:192:9e4e:36ff:fe7c:534c] has quit [Quit: Sűrű sötét az éj, dühöng a déli szél]
20141118 12:27:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141118 12:34:22-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 12:35:31-!- fabi [~quassel@p20030051AA25B99338B1188B3B12DC65.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 12:35:31-!- fabi [~quassel@p20030051AA25B99338B1188B3B12DC65.dip0.t-ipconnect.de] has quit [Changing host]
20141118 12:35:31-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 12:42:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20141118 12:45:19-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 12:45:51-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 13:03:16-!- kex [~kex@78.157.29.160] has quit [Remote host closed the connection]
20141118 13:12:58-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20141118 13:17:26< zookeeper> spamplosion on forums, ban-capability needed
20141118 13:54:01-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Ping timeout: 272 seconds]
20141118 13:54:05-!- fendrin [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 13:56:44-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Read error: Connection reset by peer]
20141118 13:57:29< vultraz> oh
20141118 13:57:31< vultraz> my god
20141118 13:58:48< vultraz> I'm going to delete some of these
20141118 13:58:56< vultraz> Leave one for shadowm to ban the guy
20141118 14:08:19< vultraz> Ok, who deleted the last two?
20141118 14:08:26< vultraz> Ah
20141118 14:08:28< vultraz> Pent
20141118 14:13:06< vultraz> shadowm: seems pent went and deleted the last topics, can you make sure the guy is banned
20141118 14:25:34-!- fendrin [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 14:26:51-!- fabi [~quassel@p20030051AA25B97744E127FEADAD102F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 14:26:51-!- fabi [~quassel@p20030051AA25B97744E127FEADAD102F.dip0.t-ipconnect.de] has quit [Changing host]
20141118 14:26:51-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 14:34:36-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 14:37:10-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 14:40:42-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20141118 14:42:01-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 14:43:29-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20141118 14:44:31-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141118 14:46:12-!- Sulfur [~Miranda@p5B327A55.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 14:51:56-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141118 14:54:54-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 14:56:31-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 258 seconds]
20141118 14:58:21< vultraz> mattsc: I found an orphaned ai page: http://wiki.wesnoth.org/AI_sfrca
20141118 14:58:29< vultraz> if it's relevant I'll un-orphan it
20141118 15:02:00< mattsc> vultraz: hmm, that’s from this year’s GSoC project, which, as it says at the end, didn’t really get to a useful state.  Still, I’m a bit hesitant to remove it.
20141118 15:04:50< mattsc> I don’t know maybe it could be linked from the 2014 GSoC page and from the AI category page?
20141118 15:04:58< mattsc> Its title should also be changed
20141118 15:13:44< vultraz> To what?
20141118 15:14:47< AI0867> shadowm: coverity scan is done. 19 defects fixed, 15 new ones
20141118 15:14:59< vultraz> Oh deer, seems a bunch of other orphaned AI pages too...
20141118 15:15:52< mattsc> vultraz: spell out what the acronym stands for
20141118 15:16:01< vultraz> Ah
20141118 15:17:41< vultraz> Ok, I'll just make a pastebin of all the orphaned AI-related page
20141118 15:18:25< mattsc> vultraz: okay, I’ll check them out later
20141118 15:20:25< vultraz> mattsc: http://pastebin.com/mPCbFwjR
20141118 15:20:41< vultraz> many of them seem to be related to GCI/GSoC proposals that didn't get accepted
20141118 15:21:19< mattsc> shouldn’t those be linked to from the respective GSoC years' pages?
20141118 15:21:30< mattsc> As in, aren’t they?
20141118 15:21:50< vultraz> They're orphaned, not linked anywhere
20141118 15:22:52< vultraz> I don't know whether it's worth keeping them around
20141118 15:23:03< vultraz> I doubt it, if they were never accepted and are for years past
20141118 15:24:38< mattsc> I don’t know.  I think they count as “interesting history of Wesnoth” (real world Wesnoth, not fantasy Wesnoth) and might be worth keeping for that reason.
20141118 15:24:42< mattsc> But I don’t know.
20141118 15:32:03< vultraz> What about the others?
20141118 15:32:39< mattsc> I’ll check those out in a little while.
20141118 15:33:04-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20141118 15:46:23-!- noy [~Noy@184.69.143.198] has joined #wesnoth-dev
20141118 15:46:30-!- noy [~Noy@184.69.143.198] has quit [Changing host]
20141118 15:46:30-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 15:54:37-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20141118 15:55:06-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has quit [Ping timeout: 255 seconds]
20141118 16:07:00-!- gfgtdf [~chatzilla@d110090.adsl.hansenet.de] has joined #wesnoth-dev
20141118 16:09:38< fabi> hello
20141118 16:13:29< mattsc> hi fabi
20141118 16:13:56< mattsc> vultraz: the following pages can be deleted:  AI_HotRedeployment FormulaAI_Tips LuaAI(old)
20141118 16:14:22< mattsc> I don’t know about this one: GCI/Port_AI_WML_configuration_to_new_style_syntax
20141118 16:14:43< mattsc> It looks like a Google Code-In page and should therefore be kept for the same reasons as the GSoC pages
20141118 16:15:36< mattsc> This one needs to be kept: LuaAI_New_Syntax
20141118 16:16:13< mattsc> vultraz: could you rename that to “Lua AI: External Candidate Actions” or something along those lines and then I will link to it from the appropriate place?
20141118 16:16:32< mattsc> Everything else are GSoC pages, I think
20141118 16:17:48< vultraz> mattsc: will do, thanks
20141118 16:23:55< vultraz> mattsc: http://wiki.wesnoth.org/Lua_AI:_External_Candidate_Actions
20141118 16:27:09< mattsc> vultraz: thanks - I’ll de-orphan it (sometime later today)
20141118 16:31:10-!- mjs-de [~mjs-de@g228170247.adsl.alicedsl.de] has joined #wesnoth-dev
20141118 16:38:55< vultraz> mattsc: I also cleaned up the formatting a bit on that page. And, do you still want me to rename AIsfrca?
20141118 16:39:59< mattsc> vultraz: yes, please
20141118 16:40:43-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141118 16:41:02< vultraz> mattsc: http://wiki.wesnoth.org/Strategy_Formulation_with_RCA_AI
20141118 16:41:47< mattsc> thanks
20141118 16:45:10-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 265 seconds]
20141118 17:18:10-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds]
20141118 17:18:17< vultraz> shadowm: question, shouldn't the Advanced Manipulation section be removed from http://wiki.wesnoth.org/FutureWML since we now have Lua? I also propose the rest of that page be merged into EasyCoding or NotSoEasyCoding (cc iceiceice)
20141118 17:25:50-!- happygrue [~Laptop@wesnoth/developer/wintermute] has joined #wesnoth-dev
20141118 17:31:18< gfgtdf> vultraz: i agree
20141118 17:33:46< vultraz> gfgtdf: to EasyCoding?
20141118 17:34:32< gfgtdf> vultraz: that Advanced Manipulation  can be removed, but i also dont see a reason against moving it to (notso-)easycoding
20141118 17:35:12< vultraz> Alright, I'll stick it in Easy, if someone wants to move it later, they can
20141118 17:37:25< Ivanovic> shadowm: yes, only patching windows sounds okay to me
20141118 17:37:50< Ivanovic> but make sure to talk to loonycyborg about the name of the exe ASAP so that you can update the announcement and translators can still fix the new fuzzy
20141118 17:38:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141118 17:38:53< vultraz> gfgtdf: done
20141118 17:49:12-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20141118 17:50:38-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 17:52:01-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 18:05:58-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141118 18:17:07-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 18:17:39-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 18:26:53-!- Sulfur [~Miranda@p5B327A55.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141118 18:37:41-!- happygrue [~Laptop@wesnoth/developer/wintermute] has quit [Read error: Connection reset by peer]
20141118 18:51:49-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 18:58:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20141118 18:58:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141118 18:59:14< timotei> 15 new defect(s) introduced to Wesnoth found with Coverity Scan.
20141118 18:59:14< timotei> 19 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
20141118 19:02:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20141118 19:02:47-!- DCW [~Thunderbi@cpc66866-finc15-2-0-cust47.4-2.cable.virginm.net] has joined #wesnoth-dev
20141118 19:10:27-!- iceiceice [~chris@50.245.222.235] has joined #wesnoth-dev
20141118 19:10:29-!- iceiceice [~chris@50.245.222.235] has quit [Changing host]
20141118 19:10:29-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20141118 19:11:45< iceiceice> AI0867, shadowm : i looked here for instructions about how to integrate coverity with travis, so that we can automatically trigger coverity scans by pushing to a special "coverity_scan" branch
20141118 19:11:47< iceiceice> https://scan.coverity.com/travis_ci
20141118 19:12:00< iceiceice> it says we could do this something like 2-4 times a week
20141118 19:12:03< iceiceice> if we wanted
20141118 19:12:19< iceiceice> however, i cannot complete the setup because i don't get the special encryption key,
20141118 19:12:27< iceiceice> i think it requires someone who is an "owner" of the github repo
20141118 19:15:14-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Client Quit]
20141118 19:16:09-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 19:17:38-!- czlowiek-zupa is now known as vifon
20141118 19:17:56-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20141118 19:25:04-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 19:34:03-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20141118 19:34:35-!- DCW [~Thunderbi@cpc66866-finc15-2-0-cust47.4-2.cable.virginm.net] has quit [Remote host closed the connection]
20141118 19:36:03-!- Sulfur [~Miranda@p5B327A55.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141118 19:46:59-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20141118 19:47:05-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20141118 19:56:50-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 20:01:08-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 20:02:01-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20141118 20:07:54-!- ToBeCloud [uid51591@gateway/web/irccloud.com/x-zauwiaixxvkccazh] has joined #wesnoth-dev
20141118 20:18:18-!- travis-ci [~travis-ci@ec2-23-20-209-21.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 20:18:18< travis-ci> cbeck88/wesnoth#1 (master - c43f988 : Ignacio R. Morelle): The build passed.
20141118 20:18:18< travis-ci> Build details : http://travis-ci.org/cbeck88/wesnoth/builds/41398576
20141118 20:18:18-!- travis-ci [~travis-ci@ec2-23-20-209-21.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 20:18:41-!- Sulfur [~Miranda@p5B327A55.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141118 20:19:08-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 20:21:15-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20141118 20:37:30-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141118 20:45:52-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20141118 20:46:11-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20141118 20:47:01-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141118 20:53:11-!- travis-ci [~travis-ci@ec2-54-92-156-116.compute-1.amazonaws.com] has joined #wesnoth-dev
20141118 20:53:11< travis-ci> cbeck88/wesnoth#2 (1.12 - 1482e8d : Ignacio R. Morelle): The build passed.
20141118 20:53:11< travis-ci> Build details : http://travis-ci.org/cbeck88/wesnoth/builds/41402878
20141118 20:53:11-!- travis-ci [~travis-ci@ec2-54-92-156-116.compute-1.amazonaws.com] has left #wesnoth-dev []
20141118 21:05:25-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20141118 21:23:05-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Read error: Connection reset by peer]
20141118 21:37:01-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has joined #wesnoth-dev
20141118 22:10:48-!- gfgtdf_ [~chatzilla@f054131071.adsl.alicedsl.de] has joined #wesnoth-dev
20141118 22:13:05-!- gfgtdf [~chatzilla@d110090.adsl.hansenet.de] has quit [Ping timeout: 272 seconds]
20141118 22:13:13-!- gfgtdf_ is now known as gfgtdf
20141118 22:25:36-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Bye for now]
20141118 22:27:50-!- ToBeCloud [uid51591@gateway/web/irccloud.com/x-zauwiaixxvkccazh] has quit [Quit: Connection closed for inactivity]
20141118 22:33:49-!- ToBeCloud [uid51591@gateway/web/irccloud.com/x-xmmrsuvmvxpzwoyv] has joined #wesnoth-dev
20141118 22:38:54-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141118 22:53:32-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20141118 22:56:05-!- Coffee_irc [~david@ppp121-45-16-149.lns20.adl2.internode.on.net] has joined #wesnoth-dev
20141118 23:10:48-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20141118 23:11:35-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141118 23:15:53-!- irker783 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20141118 23:15:53< irker783> wesnoth: gfgtdf wesnoth:1.12 01c3d7c38dd4 / src/filesystem_boost.cpp: use generic_string()  http://git.io/EPg-Iw
20141118 23:15:54-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20141118 23:19:16-!- mjs-de [~mjs-de@g228170247.adsl.alicedsl.de] has quit [Remote host closed the connection]
20141118 23:56:05-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
--- Log closed Wed Nov 19 00:00:25 2014