--- Log opened Sat Nov 15 00:00:26 2014
20141115 00:07:41-!- molgrum [~molgrum@212.85.89.43] has quit [Quit: Lämnar]
20141115 00:10:54< iceiceice> mattsc: i made a PR to disable the SOS thing,
20141115 00:11:04< iceiceice> i tested with SigurdFD's campaign on 1.11 server
20141115 00:11:11< iceiceice> it seems to work but if anyone could test it would be appreciated
20141115 00:12:52-!- travis-ci [~travis-ci@ec2-54-197-47-213.compute-1.amazonaws.com] has joined #wesnoth-dev
20141115 00:12:52< travis-ci> wesnoth/wesnoth#4761 (master - c63191b : Chris Beck): The build was fixed.
20141115 00:12:52< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/40935935
20141115 00:12:52-!- travis-ci [~travis-ci@ec2-54-197-47-213.compute-1.amazonaws.com] has left #wesnoth-dev []
20141115 00:26:24< mattsc> iceiceice: thanks - I can’t test this right now, but maybe in 1.5 - 2 hours, if nobody else has gotten around to it by then yet.
20141115 00:32:13-!- mjs-de [~mjs-de@f048082151.adsl.alicedsl.de] has quit [Remote host closed the connection]
20141115 01:18:55-!- gfgtdf [~chatzilla@f054061241.adsl.alicedsl.de] has joined #wesnoth-dev
20141115 01:19:52-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20141115 01:22:53-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20141115 01:26:42-!- irker791 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20141115 01:26:43< irker791> wesnoth: gfgtdf wesnoth:master 9833fa465762 / src/game_initialization/ (connect_engine.cpp connect_engine.hpp): make "player_id" the controlling client's id for ai sides. http://git.io/lDRXyA
20141115 01:26:44< irker791> wesnoth: gfgtdf wesnoth:master 69829d6b6603 / src/server/game.cpp: simplify serversided controller tweaks http://git.io/GLcK6w
20141115 01:26:46< irker791> wesnoth: gfgtdf wesnoth:master 1d6d7a9c1d20 / src/game_initialization/connect_engine.cpp: fix leader names in mp http://git.io/WW6Ifw
20141115 01:26:48< irker791> wesnoth: gfgtdf wesnoth:master 027dc80c4dd1 / src/server/game.cpp: remove unneeded check http://git.io/R412xA
20141115 01:26:50< irker791> wesnoth: gfgtdf wesnoth:master 7da44d91dc42 / src/ (variable.cpp variable.hpp): fix segfault in [replace_map] http://git.io/HLh6wg
20141115 01:26:52< irker791> wesnoth: gfgtdf wesnoth:master af89a91de7e6 / src/game_initialization/connect_engine.cpp: fix [side]controller= in mp_connect http://git.io/WNxV1Q
20141115 01:26:54< irker791> wesnoth: gfgtdf wesnoth:master 48fa14d49c7b / src/game_initialization/connect_engine.cpp: "Anonymous local player" -> "Anonymous player" http://git.io/jCeDUQ
20141115 01:26:56< irker791> wesnoth: gfgtdf wesnoth:master 8a6a3cc476d9 / src/game_initialization/multiplayer_wait.cpp: fixup user_description generation http://git.io/8cQrnw
20141115 01:26:58< irker791> wesnoth: gfgtdf wesnoth:master bb9b00b7707a / src/game_initialization/connect_engine.cpp: fix value of "current_player" in mp_connect http://git.io/TbGlIQ
20141115 01:38:34-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141115 01:40:55< iceiceice> gfgtdf: regarding this one: https://github.com/wesnoth/wesnoth/commit/69829d6b660333bfea89728dbb89e836c42e6dbb
20141115 01:41:10< iceiceice> the reason the server "converts all ai to network ai" is because thats how it looks to an observer if they join
20141115 01:41:27< gfgtdf> iceiceice: y i know
20141115 01:41:30< iceiceice> ok
20141115 01:48:28< iceiceice> git status
20141115 01:48:30< gfgtdf> iceiceice: do you know what this function  https://github.com/wesnoth/wesnoth/blob/bb9b00b7707afd0bf1ec4b7292341d5acf09600f/src/game_initialization/connect_engine.cpp#L739 does?
20141115 01:48:38< iceiceice> hmm
20141115 01:50:06< gfgtdf> iceiceice: i think its called here: https://github.com/wesnoth/wesnoth/blob/b0e6b23a9180630cc73a12c9cdeb0d721015efdb/src/game_initialization/multiplayer_ui.cpp#L224
20141115 01:50:21< gfgtdf> iceiceice: it seems liek its intended that the host itself can be teh server
20141115 01:50:34< gfgtdf> iceiceice: but that not possible
20141115 01:50:46< iceiceice> it might be left over code from liek 1.4 or whatever
20141115 01:50:57< gfgtdf> iceiceice: hm maybe we shoudl delete it then
20141115 01:51:26< iceiceice> gfgtdf: the second one you linked to is from 2005
20141115 01:51:55< gfgtdf> iceiceice: also see the comment here: https://github.com/wesnoth/wesnoth/blob/master/src/playturn.cpp#L136
20141115 01:51:57< iceiceice> https://github.com/wesnoth/wesnoth/commit/9ad4a96b
20141115 01:52:02< iceiceice> it looks like its from 1.0 rc1
20141115 01:52:09< iceiceice> i think it can be deleted
20141115 01:53:57< shadowm> The game client *used* to have a built-in server, but it was dropped in 1.5.x or so in favor of using wesnothd.
20141115 01:54:16< gfgtdf> shadowm: so you also think this code can be deleted ?
20141115 01:54:24< shadowm> It was very limited in functionality IIRC and had bugs of its own.
20141115 01:55:03< shadowm> I think we don't need to support 8086 CPUs either.
20141115 01:56:15< gfgtdf> shadowm: besides that i dotn know about cpu numbers, is the cpu thing related to the wesnothd thing ?
20141115 01:56:35< shadowm> The 8086 is the 286's predecessor.
20141115 01:57:35< iceiceice> wow i didnt even know that
20141115 01:57:54< shadowm> I'm merely pointing out by analogy that nobody would specifically want to keep code for a deliberately removed buggy feature around.
20141115 01:57:58< iceiceice> i had a 286 when i was a kid, but for me taht is the dawn of time
20141115 01:58:10< iceiceice> idk before that is like, eniac?
20141115 01:58:14< iceiceice> haha
20141115 01:58:58< shadowm> AMD64/Intel64 CPUs still have a limited 8086 compatibility sandbox mode that is rendered inaccessible in long mode (a.k.a. 64-bit mode).
20141115 02:00:36< shadowm> Tune in tomorrow for another Useless Shadow-Fact of the Day.
20141115 02:01:27< iceiceice> shadowm: i will follow you on twitter if you start tweeting daily "useless shadow-facts of the day"
20141115 02:01:34< iceiceice> i don't even have twitter
20141115 02:05:09< iceiceice> ok, lua noob question:
20141115 02:05:21< iceiceice> if i want to make a collection of lua functions for an add-on,
20141115 02:05:37< iceiceice> is it better to use like " [lua] code = {./my_stuff.lua} [/lua"
20141115 02:05:52< iceiceice> or try to use "wesnoth.require" in whatever script
20141115 02:06:20< iceiceice> it appears to me that "wesnoth.require" is only for stuff in the data/ folder and not add-ons but i'm not sure
20141115 02:06:57< gfgtdf> iceiceice: no wesnoth.require is also for addons teh normal thign to to
20141115 02:07:15< gfgtdf> iceiceice: the onyl case where you want to include it with {}
20141115 02:07:30< gfgtdf> iceiceice: it when you want mp addons taht dont require download
20141115 02:07:34< gfgtdf> that*
20141115 02:07:41< iceiceice> oh
20141115 02:07:43< shadowm> I normallly use dofile.
20141115 02:07:45< iceiceice> ok, i'm in that case
20141115 02:07:49< shadowm> wesnoth.dofile, to be specific.
20141115 02:09:37< shadowm> I suspect that if you use {} to include the Lua file, you'll run into problems if your code includes braces unless you do something hacky like starting the file with "-- <<" and ending it with "-- >>".
20141115 02:09:57< shadowm> The "run into problems" part is guaranteed, the solution is not.
20141115 02:10:19< gfgtdf> shadowm: i succesfuly used taht solution
20141115 02:10:25< gfgtdf> shadowmin my addon
20141115 02:10:25< iceiceice> shadowm: for what it's worth we do that in a core scenario: https://github.com/wesnoth/wesnoth/blob/master/data/multiplayer/scenarios/2p_Hornshark_Island.cfg#L81
20141115 02:11:09< iceiceice> and they do put << and >> in the file: https://github.com/wesnoth/wesnoth/blob/master/data/multiplayer/scenarios/2p_Hornshark_Island_lua
20141115 02:11:11< gfgtdf> iceiceice: that lua file onyl uses << and >>
20141115 02:11:31< shadowm> Okay. The -- comments are optional, really, they are just to avoid confusing a Lua syntax highlighter (or interpreter, if you ever feel inclined to do that).
20141115 02:11:31< gfgtdf> iceiceice: if you use --<< and -->> you ca load it with require/dofile and with marcos
20141115 02:11:57< iceiceice> ah i see
20141115 02:12:59< shadowm> It's more or less equivalent to embedded Javascript in XHTML files using a commented-out CDATA element to avoid confusing XML parsers.
20141115 02:13:22< gfgtdf> iceiceice: but the dofile version has advantages
20141115 02:13:37< gfgtdf> iceiceice: first you dotn need to reload teh config to reload teh lua scrpit
20141115 02:13:47< gfgtdf> iceiceice: whcih is quiet useful for developing
20141115 02:13:52< iceiceice> gfgtdf: yeah but i want the add-on to be no download required
20141115 02:13:59< iceiceice> because it doesn't have any content and its always been that way
20141115 02:14:02< gfgtdf> iceiceice: also it doenst slowdoan configloading
20141115 02:14:54< gfgtdf> iceiceice: for my addon i use code liek this: http://pastebin.com/TqxWKUE0 so can can have a macro stwicth whether to use loadfiel or marcoinclusion
20141115 02:15:07< gfgtdf> iceiceice: that i ahve set while developing
20141115 02:17:20< iceiceice> ok thanks
20141115 02:18:34< gfgtdf> iceiceice: also dofile gies better erro messages
20141115 02:18:44< gfgtdf> iceiceice: becasue it gives you the linenumber of the file
20141115 02:19:05< gfgtdf> in the file
20141115 02:19:30< iceiceice> gfgtdf: i had an idea that it might be possible to give a simple grammar for all of WML
20141115 02:19:40< iceiceice> so that we could use a parser generator like YACC or BISON
20141115 02:19:46< iceiceice> throw out our old parser
20141115 02:19:49< iceiceice> and get much better error messages
20141115 02:21:06< iceiceice> for instance they do it for lua in section 9 here: http://www.lua.org/manual/5.2/manual.html
20141115 02:21:31< gfgtdf> iceiceice: but wml for example macros
20141115 02:21:43< gfgtdf> has*
20141115 02:22:09< gfgtdf> iceiceice: you mean pasting error in ingme event errors ?
20141115 02:22:19< gfgtdf> or*
20141115 02:23:06-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141115 02:23:13< iceiceice> i mean like, make the parser smarter and catch more problems earlier
20141115 02:23:16< shadowm> I'm glad I was pointed to this conversation since as everyone knows I'm the last person who has dealt with the WML parser and preprocessor's diagnostics and who plans to revisit the issue for 1.14.x.
20141115 02:23:34< iceiceice> right now the parser does almost nothing
20141115 02:23:53< iceiceice> shadowm: i'm just throwing ideas around, i have no actual experience with using yacc or bison
20141115 02:23:58< iceiceice> i vaguely remember them from some silly compilers class
20141115 02:24:13< iceiceice> gfgtdf: what i mean is like,
20141115 02:24:29< iceiceice> ok so i'm not sure if it makes sense to integrate preprocessor with the thing i'm talking about
20141115 02:24:42< iceiceice> i dont know how C does that for instance, maybe preprocessor is usualyl thoguht of as separate from grammar
20141115 02:24:56< iceiceice> maybe it can be integrated though, our preprocessor is not too sophisticated thankfully
20141115 02:25:26< iceiceice> gfgtdf, shadowm: what i mean is like, afaict the preprocessor only has the goal to read a giant macro expanded text file and convert to config object
20141115 02:25:42< iceiceice> "config" is like the abstract syntax tree of wesnoth
20141115 02:26:00< iceiceice> but its totally vanilla in terms of, having understanding of what's going on
20141115 02:26:11< irker791> wesnoth: gfgtdf wesnoth:master 64edd3d1005c / src/game_initialization/ (6 files): remove part of anicent wesnothserver implementation http://git.io/_RVSqA
20141115 02:26:20< iceiceice> in lua, if you have a malformed "if" expression, it flags it as soon as you run loadstring
20141115 02:26:32< iceiceice> it already gets syntax checked at that step
20141115 02:26:52< iceiceice> in wml anything besides "unbalanced openers and closers" is a run time error
20141115 02:27:20< shadowm> The WML preprocessor is mostly separate from the WML parser, it's just that they are too often used in conjunction so people tend to equate both things.
20141115 02:27:37< iceiceice> yeah i think probably it should stay that way i guess
20141115 02:27:50< shadowm> There is also one thing both the preprocessor and parser understand.
20141115 02:29:13< shadowm> The #textdomain directive. (Not to be confused with the <FE>textdomain directive.)
20141115 02:29:27< iceiceice> yeah, i've noticed this,
20141115 02:29:35< iceiceice> i think it could become part of the grammar though
20141115 02:30:47< iceiceice> one alleged advantage of having a clearly defined grammar is that you can use standard parser tools to help write any "extra stuff" you want for the language
20141115 02:30:52< shadowm> The thing is that the WML "grammar" is context-dependent.
20141115 02:31:11< iceiceice> shadowm: i think that might be okay though
20141115 02:31:20< iceiceice> i mean the grammar can be as precise or imprecise as you want
20141115 02:31:56< iceiceice> i mean you could just define it as "it's like the XML grammar but with [ ] instead of < >, and with #textdomain directives at random points"
20141115 02:31:57< shadowm> Save games use a "grammar" superset that includes scenario WML. Scenario/era/unit type WML uses a "grammar" that may be changed by Lua.
20141115 02:32:02< iceiceice> but then you wouldnt' get any mileage
20141115 02:32:20< shadowm> Oh but XML barely defines anything.
20141115 02:32:31< iceiceice> right
20141115 02:32:35< iceiceice> lua defines a lot
20141115 02:32:36< shadowm> XML only really defines the syntax and how to define the grammar.
20141115 02:32:51< iceiceice> we could make as much or as little be an explicit part of the grammar as we want
20141115 02:32:53< iceiceice> i think
20141115 02:33:23< iceiceice> the point would be that, the parser could help to flag things earlier, like "[event] outside of [scenario]" if it has these concepts
20141115 02:33:35< iceiceice> or "[if] lacking any [else] [then] children"
20141115 02:33:47< iceiceice> so also the other purpose is,
20141115 02:33:58< gfgtdf> iceiceice: but liek ashdowm said [if] can be redefined by lua
20141115 02:33:58< shadowm> The actual element and attribute names at your disposal depend on the document type definition you are using, and even then you can really use anything you want without restriction if you wish to do so.
20141115 02:34:33< iceiceice> so the other benefit i could see to this is,
20141115 02:34:39< shadowm> XML is essentially more of a serialization tool than a language.
20141115 02:34:46< iceiceice> yeah
20141115 02:34:58< iceiceice> so things like yacc and bison could output a parser in pretty much any language
20141115 02:35:03< iceiceice> so we could use C++ for the executable,
20141115 02:35:11< iceiceice> but if you want to have a tool like, say wml lint,
20141115 02:35:21< iceiceice> you could make it output an equivalent parser in python
20141115 02:35:33< iceiceice> and then you don't have issues about bugs because of mismatching parser
20141115 02:35:42< iceiceice> also, you can write wml lint in a highlevel language
20141115 02:36:03< iceiceice> instead of being like "yipee thousands of lines of lowleel string operations..."
20141115 02:36:07< iceiceice> *lowlevel
20141115 02:37:17< shadowm> I've always dreamed of having a single unified library for WML so that the game and wmllint use its services instead of going separate paths.
20141115 02:37:58< shadowm> The thing is that the library should be able to emit config objects directly instead of some nonsense intermediate format.
20141115 02:39:14< shadowm> We handle a massive amount of code at a time so translating from an intermediate format to a config tree would be a ludicrous waste of time for the game.
20141115 02:39:59< iceiceice> yeah...
20141115 02:40:22< iceiceice> i never actually used one of these things, i just remember the idea
20141115 02:40:31< iceiceice> there's a series of gigantic lists here: http://en.wikipedia.org/wiki/Comparison_of_parser_generators
20141115 02:40:43< shadowm> I have never used any of those tools or written a parser.
20141115 02:40:57< shadowm> Okay, I did write a WML parser once, but it was pretty basic and buggy.
20141115 02:42:23-!- happygrue [~Laptop@wesnoth/developer/wintermute] has joined #wesnoth-dev
20141115 02:42:27< shadowm> Also, Boost has libraries for implementing parsers.
20141115 02:43:15< iceiceice> yeah i never wrote a parser either, it seems extremely painful
20141115 02:43:54< shadowm> It is, and I didn't even consider meta problems such as performance back then.
20141115 02:44:07< shadowm> Or having good diagnostics.
20141115 02:44:36< iceiceice> i mean its really fortunate that dave wanted to have explicit openers and closers everywhere,
20141115 02:44:52< iceiceice> it will make the grammar really simple and easy to parse
20141115 02:45:01< shadowm> Does anyone else remember when [end] was the closing tag for everything?
20141115 02:45:15< iceiceice> so its funny that it was only for human benefit
20141115 02:46:59< iceiceice> shadowm: i guess a different direction would be to like,
20141115 02:47:14< iceiceice> just stick with the parser we have but make stuff like wmllint use it via an api
20141115 02:47:49< shadowm> Isn't that what I said above with different words and angle?
20141115 02:47:50< iceiceice> it kind of sucks to translate stuff we have in python into lua but that would be an easy way to just make it talk to configs and skip the parsring
20141115 02:47:58< iceiceice> yeah it is
20141115 02:48:22< shadowm> ... Lua?
20141115 02:48:31< iceiceice> sure why not
20141115 02:48:37< iceiceice> we alread have bindings to config
20141115 02:48:42< shadowm> Stuff we have in Python?
20141115 02:49:06< iceiceice> yes, if wmllint were written in lua
20141115 02:49:20< iceiceice> and based on "helper.child" etc.
20141115 02:49:24< shadowm> We don't have anything in Python but a very pragmatic alternate implementation of WML that misses pretty much 50% of the parser functionality and 100% of the preproessor.
20141115 02:49:52< iceiceice> well we have a bunch of existing checks
20141115 02:50:09< shadowm> Also would we want a Lua-based wmllint when Python is quite obviously the superior alternative.
20141115 02:51:08< iceiceice> i think i'm biased, i really prefer to work in things like C++ over scripting languages like python and lua
20141115 02:51:39< iceiceice> what advantages does python have that you see
20141115 02:52:40< iceiceice> one obvious advantage to lua is that we already did all the work to make lua aware of text domains etc.
20141115 02:52:47< iceiceice> via the tstring api
20141115 02:52:50< shadowm> When you are writing C++ you have to deal with all the plumbing yourself.
20141115 02:53:11< iceiceice> yeah but i end up being more confident that everything is working at the end
20141115 02:53:12< shadowm> When I need to get my work done I usually just want to rent a room, not build a house.
20141115 02:53:31< iceiceice> i think static type checking is a really good thing
20141115 02:53:53< shadowm> You usually don't have to deal with memory allocation details in Python.
20141115 02:53:57< iceiceice> i'd much rather work in C++, or ML or derivatives
20141115 02:54:04< iceiceice> than in anything with dynamic typing
20141115 02:54:16< shadowm> Or unwieldy rules involving references, if you opt for the dogmatic no-pointers approach.
20141115 02:54:26< shadowm> vultraz stop channel hopping.
20141115 02:54:35< vultraz> shadowm: any opinion on E_H's announcement edits?
20141115 02:54:46< vultraz> wrong channel before >_<
20141115 02:54:51< shadowm> Yes.
20141115 02:55:34< shadowm> I have a very half-cooked opinion and you'll need to wait a bit longer to see its final form.
20141115 02:55:42< shadowm> Like 130 episodes at least.
20141115 02:56:22< iceiceice> it really angers me greatly that i can delete a $ somewhere in a wml file
20141115 02:56:28< iceiceice> and cause a bug i will never notice and release that way
20141115 02:57:13< shadowm> Remember the bug with persistent variables gfgtdf fixed?
20141115 02:57:20< iceiceice> no
20141115 02:57:33< iceiceice> was this recent?
20141115 02:57:34< shadowm> A std::advance on a non-bidirectional iterator.
20141115 02:57:44< shadowm> It's your persistent variables bug, come on, I even highlighted you.
20141115 02:57:50< iceiceice> i think i missed it
20141115 02:58:21< shadowm> Anyway, it really (not really) angers me how C++ allows us to commit mistakes like that too with catastrophic consequences.
20141115 02:59:00< iceiceice> where is the commit?
20141115 02:59:11< shadowm> In master.
20141115 02:59:17-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20141115 02:59:34< iceiceice> does it have a reasonbel commit message?
20141115 02:59:36< shadowm> Commit c64a1925df4df1bdc44892012c8e81dc406ded8a.
20141115 03:01:41< iceiceice> ok that is bad but at the same time i dont' know any langauge that will save you from that
20141115 03:02:13< iceiceice> the only way afaict would be if you had even more rigid typing
20141115 03:02:21-!- sachith500|2 [~kvirc@112.135.23.219] has joined #wesnoth-dev
20141115 03:02:34< iceiceice> i.e. require to pass some kidn of range object with certain constructors
20141115 03:03:12< iceiceice> there's a reason most of the code needs to be in C++
20141115 03:03:21< gfgtdf> iceiceice: what i dont understand about mp is current how we proceed to another scenario, first in https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/connect_engine.cpp#L201  we send "update_game" to the server which invokes a update_side_data() on the server and then "store_next_scenario" in https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/connect_engine.
20141115 03:03:21< shadowm> C++ allows you to shoot yourself in the foot.
20141115 03:03:22< gfgtdf> cpp#L208. shouldn't we first send the next scenario and then update the sides ??
20141115 03:03:26< shadowm> That's the point.
20141115 03:03:50< shadowm> You'll be hard pressed to find a single language that doesn't in some way.
20141115 03:04:02< gfgtdf> :( irc invaalidated my link by plaitting the post.
20141115 03:04:05< gfgtdf> splitting
20141115 03:04:08< iceiceice> shadowm: it has all the power you need to shoot yourself in the foot, but you also have the ability to create as elaborate typing / object hierarchy as you need to operate at a high level
20141115 03:04:10< shadowm> C and C++ make it just hilariously easier.
20141115 03:04:29-!- Ivanovic_ [~ivanovic@frnk-5f74d80d.pool.mediaWays.net] has joined #wesnoth-dev
20141115 03:04:32< iceiceice> thats just tedious is all
20141115 03:04:33< shadowm> iceiceice: Yes, you can do that, and that code is probably attempting to do that.
20141115 03:04:53< shadowm> "Probably" because it's so deeply wrapped in templates and typedefs I can literally understand nothing.
20141115 03:05:22< iceiceice> yeah i mean the other major criticism of C++ is that it's grammar sucks
20141115 03:05:31< iceiceice> and is undecidable or whatever, because of templates being too powerful,
20141115 03:05:37-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 240 seconds]
20141115 03:05:39< iceiceice> and therefore all diagnostics from the compiler are awful
20141115 03:05:43< shadowm> If you spend too much time fool-proofing everything you'll lose track of the original goal as well.
20141115 03:05:44< iceiceice> and no tools exist to help you
20141115 03:06:13< iceiceice> amazingly enough, WML has the some aspect of this issue also, by virtue of just not having a grammar
20141115 03:06:18< shadowm> That's why code used in production is often not strictly compliant with purist ideals.
20141115 03:06:23-!- Ivanovic_ is now known as Ivanovic
20141115 03:06:37< iceiceice> is the split over or are we still just talking to 5 minutes past versions of eachother
20141115 03:06:56< shadowm> What split?
20141115 03:07:06< iceiceice> i thoguht there was some kind of netsplit or something
20141115 03:07:11< iceiceice> the traffic seemed very wierd and laggy
20141115 03:07:19< iceiceice> maybe the wifi in this coffeeshop sucks
20141115 03:07:21< shadowm> It seems fine to me here.
20141115 03:07:24< gfgtdf> shikadibot: seen thunderstruck
20141115 03:07:24< shikadibot> gfgtdf: The person with the nick thunderstruck last spoke 9d 6h ago.  3d 5h ago they left with the message:
20141115 03:08:09< mattsc> iceiceice: tested PR #332 with LoW MP.  It seems to have the desired effect.
20141115 03:09:11< iceiceice> mattsc: we should make sure it didn't break for mainline campaigns also
20141115 03:09:30< mattsc> iceiceice: good point
20141115 03:09:43< mattsc> Need to do something quickly, be back in 5 min
20141115 03:10:46< iceiceice> gfgtdf: if we move to c++ 11, do you think it would make sense to rewrite wesnothd
20141115 03:10:52< iceiceice> so it doesn't use all this crazy "simple_wml" nonsense
20141115 03:11:04< iceiceice> it seems like if we can use move constructor with string then there is no benefit to simple_wml
20141115 03:11:21< iceiceice> or we could use standard stringspan or something
20141115 03:11:24< shadowm> I think there was another reason for simple_wml.
20141115 03:12:02< gfgtdf> iceiceice: well simple_wml is definitely not perfect event in c++03, for example it messes up translatable strings, and it has un ugly interface that forcec use ofteh to do things liek (**a)["sdsd"]
20141115 03:12:08< gfgtdf> even*
20141115 03:12:18< shadowm> But it looks like you knew that already.
20141115 03:12:34< iceiceice> http://wiki.wesnoth.org/WesnothdDesign
20141115 03:12:54< shadowm> Anyway, as far as I can tell it's not just about copy operations (in fact I don't see anything about copies in the page).
20141115 03:13:10< iceiceice> shadowm: i mean basically dave avoids copies
20141115 03:13:16< iceiceice> by passing pointers to locations in other strings
20141115 03:13:25< iceiceice> and calling that a "string span
20141115 03:13:40< shadowm> Yes, good, but high-performant code by stripping unneeded checks also seemed to be a goal.
20141115 03:13:45< mattsc> iceiceice: LoW SP still gives me a SoS save with correct recall list etc.
20141115 03:14:03< gfgtdf> iceiceice: i currently cannot upgrade to c++11 msvc 2010 support is not that good
20141115 03:14:10< iceiceice> shadowm: there is a clear cost in maintainability though
20141115 03:14:53< iceiceice> c++11 aside i wonder how much of this stuff can be done with stuff that was added to the standard since simple_wml was designed
20141115 03:15:03< iceiceice> i think the standard does allow for some of this stringspan kind of stuff
20141115 03:15:08< gfgtdf> iceiceice: for for example it doesnt suport "Inheriting constructors" or "constexpr" or "Expression SFINAE"
20141115 03:15:20< gfgtdf> iceiceice: i think that were the most important
20141115 03:15:34< gfgtdf> iceiceice: and it doesnt support user defined string literals
20141115 03:15:47< iceiceice> gfgtdf: did you see email thread about this?
20141115 03:16:16< gfgtdf> iceiceice: and some parts of rvalue references for example this http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm
20141115 03:16:54< iceiceice> gfgtdf: can i forward declare enums though? :D
20141115 03:17:05< iceiceice> to me that makes it totally worth it :)
20141115 03:17:27< gfgtdf> iceiceice: not in msvc 2010 but on later versions
20141115 03:17:32< gfgtdf> in*
20141115 03:17:52< iceiceice> gfgtdf: i sent mail to the list like a week ago about C++11,
20141115 03:18:03< gfgtdf> iceiceice: i read it now
20141115 03:21:11< mattsc> iceiceice (and gfgtdf): did a couple more tests and for all I can tell, the disabling MP SoS saves works as it should.
20141115 03:23:49< gfgtdf> matsc: do you think can/will enable them in a later 1.12.x version ?
20141115 03:24:30< mattsc> gfgtdf: I think if somebody finds a solution we absolutely should.
20141115 03:24:42< mattsc> I am not the person who knows whether we can/will find a solution though.
20141115 03:24:47< gfgtdf> mattsc: for example if its the code that load teh saves that is broken, will we still enable them if we fix them in 1.12.1 even if they cannot be loaded in 1.12.0 then ?
20141115 03:25:03< iceiceice> hmm i still fail travis apparently
20141115 03:25:13< mattsc> gfgtdf: yes, why shouldn’t we?
20141115 03:25:25< mattsc> It’s not like that breaks backward compatibility or something.
20141115 03:25:32< gfgtdf> iceiceice: to me travis looks good
20141115 03:26:00< gfgtdf> mattsc: i wanst sure whether tha falls under teh category of breakign backwards compability
20141115 03:26:05< iceiceice> gfgtdf: not my pr
20141115 03:26:14< iceiceice> https://github.com/wesnoth/wesnoth/pull/332
20141115 03:26:20< iceiceice> gcc 4.8 segfault, clang failed also
20141115 03:26:30< gfgtdf> iceiceice: then 1.12 pr ?
20141115 03:26:51< gfgtdf> iceiceice: g++-4.8: internal compiler error: Killed (program cc1plus)
20141115 03:26:58< iceiceice> yeh idk wtf that is
20141115 03:27:03< gfgtdf> iceiceice: that is not nessecariyl a segfault
20141115 03:27:19< iceiceice> y you are righ
20141115 03:27:34< gfgtdf> iceiceice: to me tha looks liek travis killed teh process and then someone calls it an error
20141115 03:27:42< gfgtdf> becasue they are all mean
20141115 03:27:46-!- TC01 [~quassel@magellan.acm.jhu.edu] has joined #wesnoth-dev
20141115 03:27:55< iceiceice> sometimes it is legitmately internal compiler error though
20141115 03:28:02< iceiceice> mattsc: maybe i will try locally all the compilers
20141115 03:28:19< gfgtdf> iceiceice: hm but
20141115 03:28:27< mattsc> iceiceice: what?
20141115 03:28:29< gfgtdf> iceiceice: its strnge that both fail at te same position
20141115 03:28:44< gfgtdf> iceiceice: well i think that change is ratehr trivial
20141115 03:28:50-!- fkhodkov [~user@2a01:d0:ffff:10ea::2] has joined #wesnoth-dev
20141115 03:28:54< iceiceice> mattsc: for some damn reason travis failed to compile with both compilers
20141115 03:29:08< iceiceice> even if its some bizarre internal compiler error,
20141115 03:29:10< mattsc> iceiceice: PR 332?
20141115 03:29:12< iceiceice> yes
20141115 03:29:23< iceiceice> https://travis-ci.org/wesnoth/wesnoth/pull_requests
20141115 03:29:30< iceiceice> i restarted builds, maybe travis will succeed this time
20141115 03:29:31< mattsc> ah, ok; sorry, running around doing bathtime and the like, so I’m a little slow following.
20141115 03:29:39< mattsc> Well, it worked with Xcode clang.
20141115 03:29:45< iceiceice> gfgtdf: it is a rather trivial change, but
20141115 03:29:53< iceiceice> if theres some nonsense in some compiler
20141115 03:30:02< iceiceice> and then mingw32 segfaults consistently or smth
20141115 03:30:07< iceiceice> then its not really safe to tag 1.12.0
20141115 03:30:24< iceiceice> we had situations before where seemingly trivial changes caused 4.6 to segfault consistently
20141115 03:31:08< iceiceice> idk what the deal is, i think that we do not have enoguh compilation firewalls.
20141115 03:31:23< iceiceice> we should have more classes implemented with pIMPL idiom
20141115 03:31:34< iceiceice> so that its not the case that 50% of our compilation units include all of the gui2 template insanity
20141115 03:31:42< iceiceice> maybe then it would stop segfaulting
20141115 03:31:48< gfgtdf> iceiceice: 
20141115 03:32:02< gfgtdf> iceiceice: teh bhuidl actual gives you a real erro message: https://s3.amazonaws.com/archive.travis-ci.org/jobs/41050122/log.txt
20141115 03:32:29< iceiceice> gfgtdf: that was the old version, i fixed that
20141115 03:32:36< gfgtdf> iceiceice: ah ok
20141115 03:33:53< gfgtdf> iceiceice: you knwo something about th mp thign i postead above ?
20141115 03:34:21< iceiceice> the old code in connect engine?
20141115 03:34:44< gfgtdf> iceiceice: no teh scenario transition
20141115 03:34:51< gfgtdf> about "update_game"
20141115 03:35:07< iceiceice> no iddint read it
20141115 03:35:09< iceiceice> i was getting irc lag
20141115 03:35:11< iceiceice> let me read it
20141115 03:35:32< shadowm> By the way, C++14 is the C++03 to C++11's C++98, so if some vendor "focuses on C++14 support" they are still required to support C++11.
20141115 03:35:34-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has quit [Remote host closed the connection]
20141115 03:36:15< shadowm> Or as much C++11 (C++14) as they are willing to support, anyway. I think ful
20141115 03:37:11< iceiceice> gfgtdf: what is the question?
20141115 03:37:49< gfgtdf> iceiceice: why we call update_side_data() befoire we send teh next scenario
20141115 03:37:57< gfgtdf> s/send/get
20141115 03:38:45< iceiceice> i have to look at the server again to piece it together,
20141115 03:38:52< iceiceice> i think probably it could be much simpler.
20141115 03:39:01< iceiceice> for instance i would much rather to get rid of "update_game"
20141115 03:39:09< iceiceice> and have the server just create a new game object when we transition
20141115 03:39:37< iceiceice> and then we could have linger mode work like normal without hacks
20141115 03:39:44< iceiceice> and it would probably be less code server side overall
20141115 03:39:56< gfgtdf> iceiceice: this commit: https://github.com/wesnoth/wesnoth/commit/8c4e11700e51cb9e30dbde971f8b7427d831b915 adds a "update_game" method that is calle dbefore we receive teh [store_next_scenario]
20141115 03:40:48< iceiceice> gfgtdf: i think before thunderstruck,
20141115 03:41:03< iceiceice> it was never the case that we call mp connect screen in between transitions
20141115 03:41:20< iceiceice> so i guess he added that so that the game would look "normally" while that is happening
20141115 03:41:32< iceiceice> i.e. not displaying "turn 40/80" but no turns
20141115 03:42:00< iceiceice> *so that the game would look normally to people idling in mp lobby
20141115 03:43:15< iceiceice> gfgtdf: note that update_side_data doesn't do anything if the game is started:
20141115 03:43:15< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/server/game.cpp#L348
20141115 03:43:16< gfgtdf> hm but we send [store_next_scenaio] shortly after that, it's not leik we send that when wwe start the game
20141115 03:43:39< gfgtdf> iceiceice: but it explicitly sets started to fale before
20141115 03:43:43< gfgtdf> false
20141115 03:43:51< iceiceice> yeah so that is when thunderstruck is making it in "connect mode"
20141115 03:44:08< iceiceice> it's really ugly imo
20141115 03:44:14< iceiceice> i mean its acceptable
20141115 03:44:16< iceiceice> but this is a hack
20141115 03:44:27< iceiceice> its like taking an object and having some method that sets "initialized_" from true to false
20141115 03:44:36< iceiceice> because... you don't want the overhead of constructing a new object?
20141115 03:45:05< gfgtdf> iceiceice: but why wo we call update_side_data there? i mean we still hvae teh odl scneario data no ?
20141115 03:45:15< iceiceice> yeah but if players dropped out of the game
20141115 03:45:24< iceiceice> we need the slots they leave behind to be vacant
20141115 03:45:43< iceiceice> oh so also,
20141115 03:45:50< iceiceice> it might be that i broke this basically
20141115 03:45:57< iceiceice> at the time that thunderstruck made his commit
20141115 03:46:00< iceiceice> there were no server tweaks
20141115 03:46:14< iceiceice> and the level_ was always kept up to date with players entering and leaving
20141115 03:46:19< gfgtdf> iceiceice: why shodul we need vacant slows for teh odl scenario
20141115 03:46:27< gfgtdf> like joing player to teh scneario we just left ?
20141115 03:46:28< iceiceice> if people want to join 
20141115 03:46:37< iceiceice> idk like, if its LoW campaign
20141115 03:46:44< iceiceice> someone hosts and poeple play one scenario,
20141115 03:46:55< iceiceice> then someone has to leave and hsot takes control
20141115 03:47:05< iceiceice> but in next scenario he wants to make that slot open again and readvertise it
20141115 03:47:24< iceiceice> i think thats the point of having the mp connect dialog happen again
20141115 03:47:39< iceiceice> i mean its not just to help you reconfigure internally, you alreayd could do that with :control etc.
20141115 03:48:29< gfgtdf> iceiceice: but dont we in nay case hve to call update_side_data() after we recived teh next scenario ? I mean the new scenaio coudl have a completely new number of sides.
20141115 03:48:56< iceiceice> i guess that's right
20141115 03:49:02< gfgtdf> iceiceice: and if we do so then our old update_side_data call will be overwrtten then anyway
20141115 03:49:06< iceiceice> is there harm to call update side data?
20141115 03:49:25< gfgtdf> iceiceice: it always hadm to do sonething that not needed becasue it confuises anyone who ready it
20141115 03:49:28< gfgtdf> harm*
20141115 03:49:34< gfgtdf> reads*
20141115 03:49:39< iceiceice> gfgtdf: imo the status is much worse in play_controller
20141115 03:49:43< iceiceice> where we have "maybe do init side"
20141115 03:49:56< iceiceice> that really confuses the hell out of me
20141115 03:50:08< iceiceice> and i think it is actually side effecting
20141115 03:50:13< iceiceice> that we call it so many times
20141115 03:50:33< iceiceice> not to change the subject though,
20141115 03:50:45< iceiceice> yeah if you want to try to remove that update side data call i think its probably fine but iw ouldnt know without testing
20141115 03:50:55< iceiceice> imo it woudl be better to get rid of the whole "update game" mechanism
20141115 03:52:51< iceiceice> mattsc: i compiled the PR with mingw32 no problems, SOS seems to work on HttT
20141115 03:53:10< gfgtdf> iceiceice: i also think we shodul add an update_side data after receiving teh [store_next_scenario]
20141115 03:53:21< iceiceice> gfgftdf: travis failed again D:
20141115 03:53:21< iceiceice> https://travis-ci.org/wesnoth/wesnoth/jobs/41057973
20141115 03:53:43< mattsc> iceiceice: yes, same for me  (using Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn))
20141115 03:54:15< mattsc> as in, I also tried with HttT, and a couple other campaigns
20141115 03:54:47< gfgtdf> iceiceice: agains it's killed
20141115 03:55:01< iceiceice> gfgtdf: it might be something really wierd like
20141115 03:55:14< iceiceice> it could be that ubuntu just updated their packages
20141115 03:55:21< iceiceice> and now something about it is broken
20141115 03:55:55< iceiceice> but the clang version is not downloaded, it is provided by travis
20141115 03:55:57< iceiceice> so it should not be broken.
20141115 03:56:55< iceiceice> also its usign the same stuff as master and master is not crashing
20141115 03:58:20< gfgtdf> iceiceice: according to some internet that might be caused by out of ran
20141115 04:00:46< gfgtdf> ram
20141115 04:08:52< gfgtdf> iceiceice: i ahve some very strange bug now
20141115 04:09:24< gfgtdf> somehot teh game generates things ilek [side] gold= a4
20141115 04:09:37< iceiceice> on 1.12?
20141115 04:09:51< gfgtdf> iceiceice: on master
20141115 04:09:54< gfgtdf> iceiceice: no wait
20141115 04:10:10< gfgtdf> iceiceice: it seems liek the config debug outputs in hexadecimal or something
20141115 04:10:29< iceiceice> gfgtdf: the only thing i can think of is,
20141115 04:10:37< gfgtdf> iceiceice: maybe somewhere we imbua hexadecimal to std::cerr
20141115 04:10:40< iceiceice> the random number generater seed
20141115 04:10:46< iceiceice> is printed with std::hex
20141115 04:10:58< iceiceice> but i didnt think that shold stick on the stream for config debuf
20141115 04:11:01< iceiceice> *debug
20141115 04:11:44< iceiceice> its not the only place we use std::hex apparently
20141115 04:12:08< gfgtdf> iceiceice: if you put std::hex in cerr AKA ..._ERR it effects everything
20141115 04:12:21< iceiceice> i think i dont do that though
20141115 04:12:26< iceiceice> i think only put it on a stringstream
20141115 04:13:02< iceiceice> hmm i guess i have this: src/mt_rng.cpp:	DBG_RND << "Seeded random with " << std::hex << random_seed_ << " with "
20141115 04:13:21< gfgtdf> iceiceice: y that migth be teh casue i think
20141115 04:13:31< iceiceice> gfgtdf: there's also this: src/terrain_translation.cpp:	std::cerr << std::hex << "src = " << src.base << "^" << src.overlay << "\t"
20141115 04:13:54< shadowm> Is it even possible to implement I/O manipulators like that which get deactivated after the line they are used in? I'm genuinely curious for a project of mine and don't have much experience with iostreams in general.
20141115 04:14:17< iceiceice> i guess that is in #if 0 though
20141115 04:14:18< shadowm> Precisely because I often find myself resorting to std::hex.
20141115 04:14:38< iceiceice> shadowm: i think my approach woudl be like,
20141115 04:14:46< iceiceice> your logger is not a std::ostream, its a class that wraps that
20141115 04:14:51< iceiceice> and its destructor does some cleanup or something
20141115 04:15:17< shadowm> I guess an alternative we have here is foo << (formatter() << std::hex << 255), but that involves instantiating an ostream temporary.
20141115 04:15:34< shadowm> er, *`).str()`
20141115 04:15:36< iceiceice> shadowm: maybe that should be how the logger works always
20141115 04:16:26< shadowm> I'd expect the intermediate ostream every time to result in non-negligible overhead.
20141115 04:16:44< iceiceice> i think thats called premature optimization
20141115 04:17:48< shadowm> (Hypothetical situation.) You are writing an improved attack dialog showing advanced stats, etc. and worrying about the performance impact of formatting individual numbers using a ostringstream.
20141115 04:18:18< iceiceice> shadowm: we have so much logger optimizations right now, the macro should basically result in a no-op unless you ahve logging turned on
20141115 04:18:24< iceiceice> so what's the issue
20141115 04:18:42< shadowm> (Hypothetical situation #2.) You are writing code to write a string to console and worrying about avoiding unnecessary copy constructor calls because your code gets called once every 10 ms.
20141115 04:18:43< iceiceice> we actually have *redundant* logger optmizations
20141115 04:18:55< shadowm> Tell me which hypothetical situation is premature optimization and which one isn't.
20141115 04:19:41< iceiceice> i think worrying about optimizing the damn logger as being more important than fixing bugs in it is premature optimization
20141115 04:19:52< iceiceice> is there any profiling evidence to show that hte logger impacts anything?
20141115 04:20:06< iceiceice> its pretty clear to me that, drawing graphics is very slow, parsing wml is very slow
20141115 04:20:09< iceiceice> the terrain builder is very slow
20141115 04:20:11< shadowm> Also note #2 is still for a *game* and not a simple fire-and-forget script.
20141115 04:20:26< iceiceice> no one is trying to optimize the things that are very slow,
20141115 04:20:42< shadowm> It barely impacts anything at the moment because most logging paths are disabled behind the macroified if/else.
20141115 04:21:19< iceiceice> shadowm: hypothetical situation #2 has nothign to do with wesnoth imo,
20141115 04:21:20< shadowm> I just specifically do not want things to be slower than they absolutely need to be when debugging with --log-debug=whatever.
20141115 04:21:32< iceiceice> shadowm: i think that is premature optimization
20141115 04:21:34< shadowm> Intrinsic performance loss is not a problem, extrinsic loss is.
20141115 04:21:51< shadowm> iceiceice: Wrong. #1 is premature, #2 isn't.
20141115 04:21:51< iceiceice> --log-debug=whatever is meant to diagnose bugs
20141115 04:21:59< iceiceice> bugs in the logger hinder that
20141115 04:22:29< shadowm> What bugs in the logger are we talking about?
20141115 04:22:53< shadowm> I/O manipulators having long-term effects? It's a design flaw, not really a bug in the logger.
20141115 04:23:13< iceiceice> ...
20141115 04:23:57< iceiceice> now you are just litigating
20141115 04:24:33< iceiceice> trying to optimize the performance of wesnoth with --log-debug=whatever screams premature optimziation to me, IMO
20141115 04:24:58< shadowm> Nobody is trying to optimize it, just trying to not make it worse than it already is.
20141115 04:25:00< iceiceice> and if there is actually some corner case where its an issue, then do it differently
20141115 04:25:10< iceiceice> nothing says you *must* use our general purpose loggers in every scenario
20141115 04:25:26< iceiceice> but i think this "what if i absolutely must spam the console every 10ms" scenario is so far from the mainstream
20141115 04:25:42-!- happygrue [~Laptop@wesnoth/developer/wintermute] has quit [Remote host closed the connection]
20141115 04:25:44< iceiceice> idk i think ti clearly goes against the philsophy expressed here: http://wiki.wesnoth.org/HackingWesnoth#Guideline_1:_Don.27t_prematurely_optimize
20141115 04:26:00< shadowm> I have read and edited that page before.
20141115 04:26:01< iceiceice> why would we not just want the loggers to always work and not confuse us iwth nonsense
20141115 04:27:32< iceiceice> also fwiw i'm not sure that 10ms is frequent enoguh that any of this memory allocation issue would matter
20141115 04:28:13< iceiceice> i have to go, bbl
20141115 04:28:14< gfgtdf> iceiceice: not that every logger call invoked a write to disk . Idk how complicates stringstreams are, but i think ther contruastion is most likeley negelctible to a diskwrite.
20141115 04:28:14-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20141115 04:28:17< shadowm> 10 ms is usually the amount of time we take to yield the processor.
20141115 04:28:21< gfgtdf> shadowm: ^
20141115 04:28:45< shadowm> *during which we yield
20141115 04:29:01< gfgtdf> i go too bb
20141115 04:29:02-!- gfgtdf [~chatzilla@f054061241.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.91 [Firefox 33.1/20141106120505]]
20141115 04:29:23< shadowm> The rest of the time we are doing actual work (including rendering) so that's a good example figure for me.
20141115 04:30:54< shadowm> gfgtdf: "Not that every logger call invoked a write to disk". I know you meant 'note', but the typoed version is actually true on Linux by default.
20141115 04:31:22< shadowm> It's only on Windows that we are forced to write stderr to disk by SDL.
20141115 04:32:02< shadowm> In any case, you are probably right as long as strings are small enough (e.g. not the output of config::debug()).
20141115 04:32:30< shadowm> And the large string overhead would go entirely away with C++11.
20141115 04:33:58< shadowm> As for the status quo: I can say at least that GUI2 dialog construction and destruction gets  dramatically slow with --log-debug=all.
20141115 04:34:17< shadowm> It's particularly noticeable with the Campaigns dialog, and I'm not even writing stderr to disk.
20141115 04:34:37< shadowm> And it's an O3 build.
20141115 04:35:16< shadowm> I was going to check what it was like in a networked MP game but libc hit an invalid free() and died.
20141115 04:44:11-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141115 05:03:53-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 265 seconds]
20141115 05:13:58-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141115 05:21:47-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20141115 05:25:43< iceiceice> shadowm: i'm really unimpressed by profiles of log-debug=all, the loggers are not meant to be used that way
20141115 05:25:57< iceiceice> i'm not sure exactly when you are talking about logging things,
20141115 05:26:23< iceiceice> it's pretty clear to me that during the game by far the most computationally intensive thing is loading, scaling, masking and blitting images
20141115 05:26:47< iceiceice> a typical image for next animation frame is 72 x 72 wtih 4 bytes per pixel
20141115 05:27:14< iceiceice> i dont know exactly what our frame rate is but its not toof far off of 10ms...
20141115 05:27:26< shadowm> Frame rate != frame length.
20141115 05:27:28< iceiceice> and the point is that we copy these wholesale maybe 4-5 times during consturction
20141115 05:27:29-!- kex [~kex@78.157.29.160] has quit [Remote host closed the connection]
20141115 05:27:35< iceiceice> shadowm: just think about order of magnitude
20141115 05:27:47< iceiceice> for logging to begin to compete with the image pipeline, 
20141115 05:27:52< shadowm> We cap at 50 fps.
20141115 05:28:12< iceiceice> you would need to be printing like, on the order of the 10,000 to 100,000 bytes in per 10ms cycle , i estimate
20141115 05:28:34< iceiceice> the point is that if you are logging that much info, theres just no way you can even make sense of it all
20141115 05:28:38< iceiceice> its not like you are going to read that, 
20141115 05:28:45< iceiceice> at best you are going to scan it for some particular flag or bad signal
20141115 05:29:00< iceiceice> and in that case, you should be making the *program* do the scanning
20141115 05:29:04< shadowm> If I admit my argument is founded on an invalid argument (ostream construction and operators having an important intrinsic performance impact) will you stop bothering me about it?
20141115 05:29:05< iceiceice> and only log when something noteworthy has happened
20141115 05:29:18< iceiceice> yes
20141115 05:29:26< shadowm> Because in hindsight it is an invalid argument. What isn't valid, however, is calling the whole thing "premature optimization".
20141115 05:29:35< shadowm> *valid either
20141115 05:30:25< shadowm> Also, we have a habit of requiring users to post their --log-debug=all output just in case.
20141115 05:30:59< iceiceice> for me, it's premature optimization unless you can explain a realistic circumstance when logging output would become a significant performance concern, and you arne't intentionally misusing the logger
20141115 05:31:12< shadowm> So you are saying GUI2 misuses the logger?
20141115 05:31:27< iceiceice> and i actually do think that log-debug=all is misusing the logger
20141115 05:31:49< iceiceice> unless you are using it just in the like first few seconds of initializing the game
20141115 05:32:10< iceiceice> trying to use log-debug=all to diagnose gui2 problems... i think its not going to work and you aren't going to get useful output
20141115 05:32:30< shadowm> Well, we don't always have a crystal ball available to know which domains to tell the user to log.
20141115 05:32:41< iceiceice> we have grep
20141115 05:33:03< shadowm> Well, we don't always have a crystal ball available to know which domains to tell the user to grep.
20141115 05:33:38< iceiceice> i would never look at logging output unless i'm looking for something specific
20141115 05:33:47< iceiceice> and if i'm experimenting,
20141115 05:33:54< iceiceice> i would add my own logging output to some gui2 files
20141115 05:33:59< iceiceice> or enable log channels i see in those files
20141115 05:33:59< iceiceice> etc.
20141115 05:34:02< shadowm> *Users*.
20141115 05:34:08< shadowm> For bug reports and Technical Support posts.
20141115 05:34:47< iceiceice> i dont think this is going to work nearly as well as you seem to think
20141115 05:35:29< iceiceice> i would never try to sift through log-debug=all output from a user, from a machine i can't easily push changes to and see the consequences
20141115 05:35:53< shadowm> It's not exactly my idea.
20141115 05:36:18< iceiceice> ok... well even if someone has actually done this,
20141115 05:36:29< iceiceice> if the game runs really slowly while they are doing it, i don't really care
20141115 05:36:47< shadowm> I'd rather not have it run more slowly than strictly necessary, that's all.
20141115 05:37:26< iceiceice> wouldn't you rather not have that gigantic log-debug=all log have every single number printed in hexadecimal?
20141115 05:37:44< shadowm> If feasible without hurting performance, yes.
20141115 05:38:44< shadowm> Which brings us back to the part above where I admit to overestimating nominal ostream construction & op overhead.
20141115 05:39:41< iceiceice> for what it's worth,
20141115 05:39:57< iceiceice> if you want to optimize log-debug=all i think probably could even optimize out the log level checks in that case
20141115 05:40:12< iceiceice> idk maybe i'm wrong
20141115 05:40:17< shadowm> I don't think we can without compiler optimizations.
20141115 05:40:35< shadowm> I mean, uh.
20141115 05:41:13< shadowm> What we have atm is essentially `if (usually_false == true) ; else foo();` How do you optimize that further?
20141115 05:41:36< shadowm> s/true/false/
20141115 05:42:00< iceiceice> idk, i wonder if function pointers can be faster than the branching, except that then they are opaque...
20141115 05:42:02< shadowm> usually_false is not a constant expression.
20141115 05:42:24< iceiceice> i mean i guess you could have a compile time "log-debug=all" option
20141115 05:42:30< iceiceice> so that loggers always just resolve to std::cerr
20141115 05:42:37< iceiceice> but thats pretty extreme
20141115 05:43:10< shadowm> Yeah, it is.
20141115 05:44:13< iceiceice> hehe
20141115 05:44:13< shadowm> There are other things that used to be decided at compile-time and wound up becoming runtime options to give us greater flexibility, so.
20141115 05:44:13< iceiceice> if the logger code is an external lib, then the user could relink with the "log-debug=all" dll
20141115 05:44:13< shadowm> (Dummy locales, small GUI resolutions, etc.)
20141115 05:44:17< iceiceice> (as if a user would actually do that)
20141115 05:44:49< shadowm> Though related to that, I believe I saw code behaving differently depending on whether a DEBUG symbol was defined at compile-time or not.
20141115 05:45:26< shadowm> Ah yes, the WML parser.
20141115 05:47:55< iceiceice> that sounds evil
20141115 05:48:27< shadowm> Nah, it just acquires the ability to remember the previous token and spit the tokenizer state every time it finds a problem.
20141115 05:48:44< iceiceice> i hope there aren't any bugs in that ability
20141115 05:48:57< iceiceice> who debugs the debuggers??
20141115 05:48:59< shadowm> It's just a simple assignment.
20141115 05:50:18< shadowm> It also changes the tokenizer's internal layout slightly, but nobody is ever going to compile the tokenizer and the parser with different preprocessor symbols defined.
20141115 05:54:20< iceiceice> hmm so actually on a more serious note,
20141115 05:54:30< iceiceice> it might not be a bad idea to run with log-debug=all periodically
20141115 05:54:36< iceiceice> and identify the spammiest stuff and remove it
20141115 05:54:53< iceiceice> i remember early on as a dev i learned that if you put -log-debug=engine,
20141115 05:55:01< iceiceice> you get spammed with a huge amount of pallete color info numbers
20141115 05:55:10< iceiceice> every time a sprite is loaded
20141115 05:55:12-!- Sulfur2 [~Miranda@p5B008990.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 05:55:15< iceiceice> which renders your log unintelligible
20141115 05:56:53< shadowm> That's not the case anymore, is it?
20141115 05:56:58< iceiceice> it is still the case
20141115 05:57:50< shadowm> Hm.
20141115 05:58:01< shadowm> `20141115 02:57:12 debug engine: color palette creation:` etc.?
20141115 05:58:06< iceiceice> yeah
20141115 05:58:50< shadowm> That looks like the result of a palette having an color range transform applied.
20141115 05:59:35< iceiceice> can it go on a more appropriately obscure channel?
20141115 05:59:50< iceiceice> or just be deleted?
20141115 06:00:24< shadowm> I don't think either is necessary:  src/game_config.cpp:320:                        DBG_NG << "color palette creation:\n";
20141115 06:01:02< iceiceice> i think it's really very inappropriate to put spam like that in a popular channel
20141115 06:01:15< iceiceice> it basically means that in any file that uses the engine channel,
20141115 06:01:23< shadowm> Hm, okay, it happens for every unit.
20141115 06:01:24< iceiceice> if i ever want intelligeible debug channel i define a new channel
20141115 06:01:32< shadowm> Wait, if it happens for every unit...
20141115 06:01:56< shadowm> Uh.
20141115 06:02:08< shadowm> [unit_type] accepts [color_range]?
20141115 06:02:27< shadowm> And so does [unit]?
20141115 06:02:43< shadowm> mind = blown
20141115 06:03:47< iceiceice> ok i don't actually know exactly when it outputs
20141115 06:03:53< iceiceice> like i said the log is unintelligible to me
20141115 06:03:55< shadowm> iceiceice: But it only happens once for every unit_type built or unit created, and during game initialization.
20141115 06:04:15< shadowm> And it doesn't happen for units or unit_types unless they actually include this data in their WML.
20141115 06:04:20< iceiceice> yeah but if you are trying to debug something from the game initialization phase that is already devastating
20141115 06:04:34< shadowm> Seeing as how I only had to read this to find out that was an actual possibility, I surmise most people don't do that.
20141115 06:04:57< shadowm> I don't know about devastating because we only have about a dozen palettes.
20141115 06:05:26< iceiceice> do you think anyone gets anything out of looking at a wall of numbers like that?
20141115 06:05:54< shadowm> Not nowadays since the color range transform is pretty stable and everyone relies on it.
20141115 06:06:17< iceiceice> i think it should be on "engine/palette" or something if you think there is value in it
20141115 06:06:20< shadowm> Maybe back in the day when it was an experimental thing.
20141115 06:06:32< shadowm> (And Wesnoth RCX didn't exist.) </shamelessplug>
20141115 06:06:39< iceiceice> hehe
20141115 06:07:46< shadowm> It's actually a pretty bad output bit because it wastes time generating a string even if the engine domain isn't set to debug severity.
20141115 06:08:14< shadowm> Then again, it's only seldom run.
20141115 06:11:36< shadowm> Okay, why are these so long anyway?
20141115 06:12:35< shadowm> Uh.
20141115 06:12:58< shadowm> It seems I accidentally discovered the mystery behind the commented-out blue palette.
20141115 06:14:09< shadowm> No wait, no, I'm reading the bitwise math wrong.
20141115 06:15:14< shadowm> Okay, what we do with color ranges that leads to that pointless debug output seems to be this:
20141115 06:15:54< shadowm> 1) We generate a synthetic palette ranging from #0000FF to #FFFFFF RGB (that's blue to white)
20141115 06:16:11< shadowm> 2) We apply the CR to that synthetic palette
20141115 06:16:30< shadowm> 3) We dump the result into a new named palette with the same name as the CR in question
20141115 06:16:51< shadowm> I'm not sure what's the purpose of this?
20141115 06:17:39< shadowm> Normally, for team coloring we apply the CR to a TC palette specified in some fashion, which is usually the magenta palette defined in data/core/team-colors.cfg.
20141115 06:18:03< shadowm> So I don't understand what the palette() nonsense in src/color_range.cpp is supposed to accomplish.
20141115 06:18:30< iceiceice> i never had any idea
20141115 06:19:27< shadowm> So what we dump in the engine logdomain is that synthetic palette.
20141115 06:20:09< shadowm> The originating commit had an empty message.
20141115 06:20:54< shadowm> !commit 28b06edc9da65dd38da0aa8a94ac75d5243c040d
20141115 06:20:56< shikadibot> shadowm: Revision 28b06edc9da6 (John W. C. McNabb) on Sun Nov 12 18:38:34 2006:
20141115 06:20:59< shikadibot> shadowm: [[Fixes for LOW_MEM behavior]]
20141115 06:21:02< shikadibot> shadowm: Web interface URL: https://github.com/wesnoth/wesnoth/commit/28b06edc9da6
20141115 06:21:34< shadowm> Double brackets for "this was the best interpretation our repository re-writer could come up with".
20141115 06:23:30< shadowm> Wow, color_ranges had a really awkward syntax at first.
20141115 06:24:13< shadowm> Okay, so I think I'll remove this code in master and see what breaks.
20141115 06:27:28< shadowm> Nothing at compile time, at least.
20141115 06:28:27< shadowm> Hm.
20141115 06:28:35< shadowm> It does break something, I don't know what.
20141115 06:28:46< shadowm> `20141115 03:27:31 error engine: Invalid color palette: red`
20141115 06:29:51< shadowm> Ah, the test scenario [item] on line 2742.
20141115 06:30:12< shadowm> And I guess the original color_range syntax is still supported too.
20141115 06:30:53< shadowm> I don't know. Would *anyone* have a use for the synthetic red palette?
20141115 06:31:45< shadowm> I mean blue.
20141115 06:32:19< shadowm> Okay, no, I mean the synthetic red(+blue), blue(+blue), green(+blue), purple(+blue), etc. palettes.
20141115 06:32:49< shadowm> This must be the most bizarre coding relic I've seen in this project.
20141115 06:33:48< shadowm> Also, #FFFFFF white is excluded from those palettes. (????????)
20141115 06:43:58< shadowm> Here is an annotated version: https://gist.github.com/shikadilord/cc4fc89667236810a43f
20141115 06:45:08< shadowm> I think I'll slap it on Wesnoth RCX later and see what the result looks like.
20141115 06:48:32< iceiceice> mattsc: i'm going to merge the disable SOS patch,
20141115 06:48:42< iceiceice> it compiles fine for me with clang gcc and mingw
20141115 06:48:48< iceiceice> so, screw travis,
20141115 06:48:57< iceiceice> i hope everyone can still compile in the morning
20141115 06:49:13< irker791> wesnoth: Chris Beck wesnoth:1.12 4dabb59b90fb / src/playcampaign.cpp: disable start of scenario saves for 1.12, "fixing" bug #22068 http://git.io/V91-Kg
20141115 06:49:15< irker791> wesnoth: Chris Beck wesnoth:1.12 e099e5c7498f / changelog: update changelog http://git.io/K8jIXw
20141115 06:49:17< irker791> wesnoth: Chris Beck wesnoth:1.12 1d99a8a12d09 / changelog src/playcampaign.cpp: Merge pull request #332 from cbeck88/disable_SOS_saves http://git.io/qFKkig
20141115 06:53:09< irker791> wesnoth: Chris Beck wesnoth:1.12 a438806c9a54 / RELEASE_NOTES: update RELEASE_NOTES http://git.io/wCX3TQ
20141115 06:53:38-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141115 06:56:52-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 250 seconds]
20141115 06:58:53-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141115 07:03:55-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 07:15:01-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20141115 07:16:21-!- kex [~kex@212.158.180.122] has joined #wesnoth-dev
20141115 07:16:41-!- kex [~kex@212.158.180.122] has quit [Read error: Connection reset by peer]
20141115 07:32:11-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141115 07:34:19-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds]
20141115 07:44:45-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141115 07:57:31-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141115 08:10:40-!- zookeeper [zookeeper@37.35.24.98] has joined #wesnoth-dev
20141115 08:10:42-!- zookeeper [zookeeper@37.35.24.98] has quit [Changing host]
20141115 08:10:43-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20141115 08:21:37-!- thunderstruck [~thunderst@cpc8-sgyl29-2-0-cust37.sgyl.cable.virginm.net] has joined #wesnoth-dev
20141115 08:22:23-!- Anakonda [Anakonda@87-92-139-179.bb.dnainternet.fi] has joined #wesnoth-dev
20141115 08:27:45-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141115 08:39:59-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20141115 08:41:52-!- Ivanovic [~ivanovic@frnk-5f74d80d.pool.mediaWays.net] has quit [Changing host]
20141115 08:41:52-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20141115 08:43:51-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141115 08:51:00-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141115 08:55:10-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20141115 08:57:55-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20141115 09:00:41-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141115 09:01:19-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141115 09:05:24< shadowm> Ivanovic: Oh yeah, don't forget to tag it as "1.12.0", not "1.12".
20141115 09:05:36< Ivanovic> okay
20141115 09:05:44< Ivanovic> internal version number also 1.12.0?
20141115 09:05:48< shadowm> Git gives me crap every time I try to look up the 1.4.0 tag because it's 1.4 and that conflicts with the branch name.
20141115 09:05:49< Ivanovic> and upload folder 1.12.0?
20141115 09:06:03< Ivanovic> or what was listed in the release announcement?
20141115 09:06:16< Ivanovic> since it should match the "to be expected" path at sf.net for the download
20141115 09:06:23< shadowm>     <li><a href='http://sourceforge.net/projects/wesnoth/files/wesnoth-1.12/wesnoth-1.12/wesnoth-1.12.tar.bz2/download'><b>Source code</b></a></li>
20141115 09:06:42< shadowm> That's what is in the announcement because it matches the format used for 1.10.0.
20141115 09:06:55< Ivanovic> okay
20141115 09:07:07< shadowm> The internal version in the source should be 1.12.0 just like the tag.
20141115 09:07:56< shadowm> (Technically, version_info("1.12.0") == version_info("1.12"), but still.)
20141115 09:15:15-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141115 09:26:09< shadowm> Ivanovic: I've got the 1.12 wesnothd running on server.wesnoth.org, accepting only clients that identify as version 1.12.0 or later (not RCs until I kill 1.11's own server) for testing purposes.
20141115 09:27:10< shadowm> I'll dump 1.11 and promote 1.12 to stable on the announcement date.
20141115 09:30:22< Ivanovic> okay
20141115 09:31:32< Ivanovic> AI0867, boucman, elias, Jetrel, lipkab, loonycyborg, mattsc, noy, Rhonda, shadowm, Soliton, thunderstruck, zookeeper, everyone else who cares: if you don't ping me within the next 5min it will be too late to stop me from tagging 1.12.0
20141115 09:34:47< shadowm> Ivanovic: Oh yes, let me commit an incredibly tiny thing first.
20141115 09:35:22< Ivanovic> shadowm: go ahead
20141115 09:35:59-!- Ivanovic changed the topic of #wesnoth-dev to: Tagging of 1.12.0 NOW | hard string+feature freeze active on 1.12 | Logs: http://irclogs.wesnoth.org | Alternate logs (down): http://wesnoth.debian.net
20141115 09:38:05< shadowm> Two tiny things.
20141115 09:39:37< irker791> wesnoth: Nils Kneuper wesnoth:1.12 fe8c111caefd / / (25 files in 24 dirs): updated Russian translation http://git.io/eqCDfw
20141115 09:39:39< irker791> wesnoth: Nils Kneuper wesnoth:master fd9bfbc42dd4 / / (26 files in 25 dirs): updated Russian translation http://git.io/QhHS7Q
20141115 09:39:41< Ivanovic> i had to upload a translation update anyway
20141115 09:42:24< irker791> wesnoth: Ignacio R. Morelle wesnoth:1.12 39e2d710bddf / data/campaigns/Legend_of_Wesmere/ (14 files in 6 dirs): wmlindent pass http://git.io/nHmMcQ
20141115 09:42:24< shadowm> Ivanovic: Done.
20141115 09:42:27< irker791> wesnoth: Ignacio R. Morelle wesnoth:1.12 f918ba309fe3 / data/campaigns/Legend_of_Wesmere/maps/Kalian_map.cfg: LoW: file-local spellchecker exceptions for wmllint http://git.io/nrE0_w
20141115 09:42:52< shadowm> i.e. 1.12 is now wmllint-clean.
20141115 09:44:26< Ivanovic> okay, who do i have to kill?
20141115 09:44:33< Ivanovic> a string in low was changed since the last release
20141115 09:45:44< shadowm> Is it from commit a35cebe6af721cf60154842be96159ef2b82c687 ?
20141115 09:46:08< Ivanovic> 39e2d710 (Ignacio R. Morelle  2014-11-15 06:35:17 -0300  87)     text=_"Dancers Green"
20141115 09:46:26< shadowm> That's from commit a35cebe6af721cf60154842be96159ef2b82c687.
20141115 09:47:44-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has joined #wesnoth-dev
20141115 09:47:51< shadowm> Ivanovic: I think it's an accident. fabi probably intended it to remain "Dancer’s Green".
20141115 09:49:01< Ivanovic> jepp, the old string was "Dancer’s Green"
20141115 09:50:29< vultraz> 'Dancers Green' doesn't really make sense
20141115 09:51:58< irker791> wesnoth: Nils Kneuper wesnoth:1.12 484abee71013 / data/campaigns/Legend_of_Wesmere/maps/Kalian_map.cfg: restored the previous form of a string change which broke the freeze http://git.io/AIc99Q
20141115 09:54:45< irker791> wesnoth: Nils Kneuper wesnoth:1.12 9644225fccf5 / / (168 files in 29 dirs): pot-update & regenerated doc files http://git.io/wJPHyQ
20141115 09:56:02< irker791> wesnoth: Nils Kneuper wesnoth:1.12 5f330510efad / Doxyfile changelog players_changelog src/wesconfig.h: bump version to 1.12.0 http://git.io/M61XEg
20141115 09:56:49-!- Ivanovic changed the topic of #wesnoth-dev to: Tagging of 1.12.0 NOW, using 5f330510efad | hard string+feature freeze active on 1.12 | Logs: http://irclogs.wesnoth.org | Alternate logs (down): http://wesnoth.debian.net
20141115 09:57:08< vultraz> Whoot whoot!
20141115 09:59:11< shadowm> All aboard the release train!
20141115 09:59:54< vultraz> So we announce next week?
20141115 10:01:17< Ivanovic> unless we find a *really* bad error
20141115 10:01:39-!- travis-ci [~travis-ci@ec2-54-89-67-2.compute-1.amazonaws.com] has joined #wesnoth-dev
20141115 10:01:39< travis-ci> wesnoth/wesnoth#4784 (1.12 - fe8c111 : Nils Kneuper): The build has errored.
20141115 10:01:39< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41079691
20141115 10:01:39-!- travis-ci [~travis-ci@ec2-54-89-67-2.compute-1.amazonaws.com] has left #wesnoth-dev []
20141115 10:04:59< Ivanovic> uploading the tarball already to wesnoth.org
20141115 10:05:04< Ivanovic> in parallel building and then testing
20141115 10:05:24< Ivanovic> upload to wesnoth.org will take about an hour
20141115 10:05:37< Ivanovic> afterwards upload to sf.net should take another 5 to 10min
20141115 10:10:51< vultraz> Ivanovic: can we remove the "previous version" links from the downloads page?
20141115 10:12:23-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141115 10:12:39< Ivanovic> ugh, i found a way how the ingame help can be broken
20141115 10:12:49< Ivanovic> shame on christoph for sending in this translation...
20141115 10:13:04< Ivanovic> if you have a = inside the help string it will look *very* strange...
20141115 10:17:19< vultraz> Also, reminds me, we have to purge devfeature1.11 from the wiki
20141115 10:17:35< shadowm> Please don't do it until we are closer to the announcement.
20141115 10:17:58< vultraz> Ok
20141115 10:18:12< vultraz> Speaking of which, what were your thoughts on EH's edit
20141115 10:18:30< shadowm> I said I need some time to put them into words.
20141115 10:19:20< vultraz> Uh huh
20141115 10:19:22< vultraz> Alright
20141115 10:19:33< vultraz> If you want my two cents, I don't really like it
20141115 10:20:46< shadowm> There is only one thing I could take from it but I haven't seen the code and have the suspicion I'll not really like it, plus it still needs further tweaking.
20141115 10:21:46< vultraz> I especially prefer your CSS-only buttons to his
20141115 10:21:57< shadowm> I actually prefer his.
20141115 10:22:08< vultraz> Also, fun fact: 1.11.0 was released on Aug 25, 2012
20141115 10:22:22< vultraz> It's now November 15th, 2014
20141115 10:22:58< shadowm> https://dl.dropboxusercontent.com/u/21371130/poop/wesmere-button-attempt.png
20141115 10:23:14< shadowm> It's very bad and I barely even tried.
20141115 10:23:41< shadowm> Plus I don't want to use radial gradients because I have some bad experiences with them from Iris.
20141115 10:24:32< vultraz> I see
20141115 10:24:58< vultraz> Well, I'll await your consensus
20141115 10:24:59< shadowm> And then there's Chrome going to **** and rendering gradients wrong on Linux. It's bad enough with linear gradients, I kind of don't want to see how bad it can get with radial ones.
20141115 10:25:17< shadowm> My... consensus?
20141115 10:25:45< vultraz> Yes.
20141115 10:25:54< shadowm> Okay, fine, let's go with the multiple shadowms model.
20141115 10:26:25< shadowm> vultraz: I'm not a committee.
20141115 10:26:56< vultraz> Your conclusions, then
20141115 10:28:32< irker791> wesnoth: Nils Kneuper wesnoth:1.12 de3aab3c7851 / po/wesnoth/de.po: fixed issue with German translation breaking help http://git.io/E8qeIQ
20141115 10:29:23< Ivanovic> okay, and again...
20141115 10:29:52< shadowm> Don't be surprised if uploading the tarball to w.o takes longer than usual because there's a backup job in progress.
20141115 10:31:52< Ivanovic> since my line here at my parents place only has 100 kilobyte per second upload i will probably not notice that
20141115 10:32:14< shadowm> Wow.
20141115 10:38:56-!- cib0 [~cib@132.231.178.84] has joined #wesnoth-dev
20141115 10:43:29-!- Sulfur2 [~Miranda@p5B008990.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141115 10:46:42-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 264 seconds]
20141115 10:53:57-!- kex [~kex@212.158.180.122] has joined #wesnoth-dev
20141115 10:58:50-!- kex [~kex@212.158.180.122] has quit [Read error: Connection reset by peer]
20141115 11:12:37-!- Sulfur2 [~Miranda@p5B008990.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 11:24:49-!- molgrum [~molgrum@212.85.89.43] has joined #wesnoth-dev
20141115 11:24:56-!- sachith500|2 [~kvirc@112.135.23.219] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20141115 11:31:14< irker791> wesnoth: ivanovic wesnoth: de3aab3c7851 tagged as 1.12.0
20141115 11:34:43-!- cib0 [~cib@132.231.178.84] has quit [Ping timeout: 272 seconds]
20141115 11:35:30< vultraz> whoot!
20141115 11:41:09-!- Ivanovic changed the topic of #wesnoth-dev to: 1.12.0 tagged, announcing Sat 22nd Nov or Sun 23rd Nov | hard string+feature freeze active on 1.12 | Logs: http://irclogs.wesnoth.org | Alternate logs (down): http://wesnoth.debian.net
20141115 11:48:23< lipkab> Oh heck, I missed the release.
20141115 11:48:37< lipkab> Now I'll have to wait another 2 years.
20141115 11:48:47-!- cib0 [~cib@132.231.178.21] has joined #wesnoth-dev
20141115 12:02:26< vultraz> lipkab: you didn't miss it, you can see it right there :P
20141115 12:03:37-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has joined #wesnoth-dev
20141115 12:04:01-!- travis-ci [~travis-ci@ec2-54-89-67-2.compute-1.amazonaws.com] has joined #wesnoth-dev
20141115 12:04:02< travis-ci> wesnoth/wesnoth#4790 (1.12.0 - de3aab3 : Nils Kneuper): The build passed.
20141115 12:04:02< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/41084406
20141115 12:04:02-!- travis-ci [~travis-ci@ec2-54-89-67-2.compute-1.amazonaws.com] has left #wesnoth-dev []
20141115 12:44:34< Ivanovic> lipkab: not all release related steps are done yet...
20141115 12:46:09< irker791> wesnoth: Nils Kneuper wesnoth:1.12 ce22bc43e434 / Doxyfile changelog players_changelog src/wesconfig.h: post release version bump to 1.12.0+dev http://git.io/YFl9BQ
20141115 12:55:32-!- Sulfur2 [~Miranda@p5B008990.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141115 13:00:21-!- cib0 [~cib@132.231.178.21] has quit [Quit: Leaving]
20141115 13:23:18-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141115 13:35:37-!- kex [~kex@212.158.180.122] has joined #wesnoth-dev
20141115 13:39:52-!- kex [~kex@212.158.180.122] has quit [Read error: Connection reset by peer]
20141115 13:40:48-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141115 13:48:41-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20141115 14:03:53-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has quit [Ping timeout: 244 seconds]
20141115 14:04:15-!- Sulfur [~Miranda@p5B008990.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 14:08:04-!- DCW [~Thunderbi@cpc66866-finc15-2-0-cust47.4-2.cable.virginm.net] has joined #wesnoth-dev
20141115 14:13:02-!- DCW [~Thunderbi@cpc66866-finc15-2-0-cust47.4-2.cable.virginm.net] has quit [Quit: DCW]
20141115 14:14:45< shadowm> Ivanovic: Will you make an Xdelta patch from 1.10.7 available as well?
20141115 14:16:28< mattsc> Woot, indeed!
20141115 14:16:38< mattsc> Thanks, Ivanovic.
20141115 14:17:11< mattsc> And thanks to everybody who worked so hard over the last weeks to make this happen!  (you know who you are)
20141115 14:31:35< Ivanovic> shadowm: ah, good idea!
20141115 14:39:49-!- sachith500 [~kvirc@112.134.115.216] has joined #wesnoth-dev
20141115 14:40:11< Ivanovic> i am off for a short while soon
20141115 14:52:08< irker791> wesnoth: gfgtdf wesnoth:master 622d4c1313c4 / src/config.cpp: fix config::get_diff http://git.io/Nb0rRA
20141115 14:52:10< irker791> wesnoth: gfgtdf wesnoth:master ec1e0f22f200 / src/server/game.cpp: use sides_.size() instead of MAX_PLAYES http://git.io/AWZ1KQ
20141115 14:52:12< irker791> wesnoth: gfgtdf wesnoth:master e5c5839109cf / src/server/server.cpp: limit variable scopes http://git.io/JD5pdQ
20141115 14:52:14< irker791> wesnoth: gfgtdf wesnoth:master 8c9a738b54ea / src/game_initialization/multiplayer_connect.cpp: don't limit gold and income in mpconnect if not neeeded http://git.io/J92LAg
20141115 14:52:15-!- cib0 [~cib@132.231.178.15] has joined #wesnoth-dev
20141115 14:52:16< irker791> wesnoth: gfgtdf wesnoth:master 113c8d8504cc / src/config.cpp: don't print blank attribute values http://git.io/4oNWNQ
20141115 14:57:40< irker791> wesnoth: gfgtdf wesnoth:master 076c6ef75f46 / src/server/game.cpp: remove unneeded check http://git.io/J-t2LQ
20141115 14:57:50-!- ToBeCloud [uid51591@gateway/web/irccloud.com/x-lxuazsrqmaoknplc] has quit [Quit: Connection closed for inactivity]
20141115 15:02:47< Rhonda> Ivanovic: nooo, I didn't finish the translation  >.>
20141115 15:19:47-!- Xudo_ [bce88790@gateway/web/freenode/ip.188.232.135.144] has joined #wesnoth-dev
20141115 15:27:56< Ivanovic> Rhonda: too late now
20141115 15:27:57< Ivanovic> ;)
20141115 15:35:49-!- sachith500 [~kvirc@112.134.115.216] has quit [Read error: Connection reset by peer]
20141115 15:36:08-!- sachith500 [~kvirc@112.134.115.216] has joined #wesnoth-dev
20141115 15:46:11-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20141115 15:51:04< Rhonda> :/
20141115 15:52:50-!- gfgtdf [~chatzilla@f054061241.adsl.alicedsl.de] has joined #wesnoth-dev
20141115 16:00:30< gfgtdf> thunderstruck: online?
20141115 16:00:44-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 265 seconds]
20141115 16:01:00< gfgtdf> thunderstruck: can you tell me more about https://github.com/wesnoth/wesnoth/commit/8c4e11700e51cb9e30dbde971f8b7427d831b915 ?
20141115 16:01:45< gfgtdf> thunderstruck: i dont understand why we do this before we store the next scenario .
20141115 16:02:13-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141115 16:04:26-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141115 16:04:55< thunderstruck> gfgtdf, Hi.
20141115 16:05:01< gfgtdf> thunderstruck: hi
20141115 16:05:30< thunderstruck> gfgtdf, IIRC, this is to keep information about MP campaigns in lobby up-to-date.
20141115 16:05:45-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Client Quit]
20141115 16:05:52< thunderstruck> gfgtdf, before this, MP lobby would would show information about a first scenerio even if you were in a 3rd one.
20141115 16:06:09< thunderstruck> gfgtdf, So I added this to update things such as scenario name, minimap etc.
20141115 16:06:55< gfgtdf> thunderstruck: but it loks like the server doesnt have the data of teh next scenario when he gets that package, so hwo does it work ?
20141115 16:07:00< gfgtdf> looks*
20141115 16:07:37< thunderstruck> gfgtdf, You think it doesn't work anymore?
20141115 16:07:51< gfgtdf> thunderstruck:  idk i ont understand it
20141115 16:07:54< gfgtdf> don't
20141115 16:09:20< thunderstruck> gfgtdf, I don't remember the exact flow of communication between MP client and server.
20141115 16:09:26< thunderstruck> It should have that data.
20141115 16:09:50< thunderstruck> I could check this a bit later and tell you exactly how it works if you want.
20141115 16:09:52-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 255 seconds]
20141115 16:10:26< gfgtdf> thunderstruck: but in mp_connect_engine we furst send the response.add_child("update_game"); and then call send_level_data(0) whcih sends teh level data i think
20141115 16:10:31< gfgtdf> thunderstruck: y that woudl be nice
20141115 16:10:51< gfgtdf> s/furst/first
20141115 16:11:22< thunderstruck> gfgtdf, I guess it was sent earlier
20141115 16:11:29< thunderstruck> gfgtdf, Possibly in play_campaign.cpp
20141115 16:11:46-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141115 16:12:47< thunderstruck> gfgtdf, Was this file renamed?
20141115 16:13:09< gfgtdf> thunderstruck: yes first to connect_engine and tehn moves to folder game_initilisation
20141115 16:13:14< gfgtdf> then*
20141115 16:14:58< gfgtdf> thunderstruck: i testes with logdebug network and we definitely send first [update_game] adn then [store_next_scenario]
20141115 16:16:45< thunderstruck> gfgtdf, Okay. I'm a bit confussed to here.
20141115 16:17:04< thunderstruck> gfgtdf, Anyway, this is not just for [update_game].
20141115 16:17:12< thunderstruck> Same goes for [create_game].
20141115 16:18:12< gfgtdf> thunderstruck: well yes we have to create the wesnothd::game before we put data into it i guess
20141115 16:18:46< gfgtdf> thunderstruck: i am eating now
20141115 16:20:02-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has quit [Remote host closed the connection]
20141115 16:20:30< thunderstruck> gfgtdf, Yes, you are right here.
20141115 16:20:44< thunderstruck> gfgtdf, I'm also going to eat now.
20141115 16:25:40-!- cib0 [~cib@132.231.178.15] has quit [Ping timeout: 258 seconds]
20141115 16:36:33-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has quit [Remote host closed the connection]
20141115 16:54:09< mattsc> Ivanovic, shadowm: the OS X package is up on SF  (not that it’s urgent)
20141115 16:56:09-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20141115 17:05:00< irker791> wesnoth: mattsc wesnoth:1.12 6ac462558878 / projectfiles/Xcode/ (3 files in 2 dirs): Xcode project update for 1.12.0 http://git.io/GZA6gw
20141115 17:09:12-!- thunderstruck [~thunderst@cpc8-sgyl29-2-0-cust37.sgyl.cable.virginm.net] has quit [Quit: Leaving]
20141115 17:10:23< gfgtdf> thunderstruck: i finished eatign now
20141115 17:25:15-!- sachith500 [~kvirc@112.134.115.216] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20141115 17:39:53< irker791> wesnoth: gfgtdf wesnoth:master 97bf7a08e2e5 / src/server/server.cpp: use .size() instead of counting manually http://git.io/bVM1EQ
20141115 17:49:53-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141115 17:51:16-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 17:59:49< irker791> wesnoth: gfgtdf wesnoth:master 7fdc1eed56e5 / src/server/game.cpp: fix mp reloading http://git.io/GOi1RQ
20141115 18:18:02-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141115 18:34:23-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141115 18:39:32-!- trewe [~trewe@188.251.24.225] has joined #wesnoth-dev
20141115 18:44:21-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141115 18:48:34-!- lobby [~wesnoth@wesnoth/bot/lobby] has quit [Ping timeout: 245 seconds]
20141115 18:48:46-!- lobby_ [~wesnoth@wesnoth/bot/lobby] has joined #wesnoth-dev
20141115 18:48:46-!- Topic for #wesnoth-dev: 1.12.0 tagged, announcing Sat 22nd Nov or Sun 23rd Nov | hard string+feature freeze active on 1.12 | Logs: http://irclogs.wesnoth.org | Alternate logs (down): http://wesnoth.debian.net
20141115 18:48:46-!- Topic set by Ivanovic [~ivanovic@wesnoth/developer/ivanovic] [Sat Nov 15 11:41:09 2014]
20141115 18:48:46[Users #wesnoth-dev]
20141115 18:48:46[ AI0867         ] [ elias    ] [ higgins    ] [ matthiaskrgr] [ Samual         ] [ trewe    ] 
20141115 18:48:46[ Anakonda       ] [ EliDupree] [ irker791   ] [ mattsc      ] [ shadowm        ] [ vifon    ] 
20141115 18:48:46[ Ard0nik        ] [ enchilado] [ Ivanovic   ] [ molgrum     ] [ shadowm_desktop] [ vultraz  ] 
20141115 18:48:46[ boucman        ] [ esr      ] [ iwaim      ] [ noy         ] [ shikadibot     ] [ Xudo_    ] 
20141115 18:48:46[ bumbadadabum   ] [ fkhodkov ] [ janebot_   ] [ nurupo      ] [ Smar           ] [ yann     ] 
20141115 18:48:46[ c74d           ] [ Fortescue] [ Jetrel     ] [ oldlaptop   ] [ Soliton        ] [ yarker   ] 
20141115 18:48:46[ cib0           ] [ Frainz   ] [ kex        ] [ Pepe_       ] [ Sulfur         ] [ zookeeper] 
20141115 18:48:46[ Crendgrim      ] [ Gambit   ] [ lipkab     ] [ prkc        ] [ TC01           ] [ {V}      ] 
20141115 18:48:46[ crimson_penguin] [ gfgtdf   ] [ lobby_     ] [ Ravana_     ] [ timotei_       ] 
20141115 18:48:46[ DDR            ] [ Haudegen ] [ loonycyborg] [ Rhonda      ] [ ToBeFree       ] 
20141115 18:48:46[ DHost          ] [ heirecka ] [ MaraJade   ] [ ryao        ] [ tomreyn        ] 
20141115 18:48:46-!- Irssi: #wesnoth-dev: Total of 63 nicks [0 ops, 0 halfops, 0 voices, 63 normal]
20141115 18:48:52-!- Channel #wesnoth-dev created Tue Jan 27 05:28:41 2009
20141115 18:49:54-!- Irssi: Join to #wesnoth-dev was synced in 79 secs
20141115 18:57:41-!- janebot__ [~Gambot@grickit.us] has joined #wesnoth-dev
20141115 18:59:58-!- bumbadadabum_ [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20141115 19:00:16-!- matthiaskrgr [matthiaskr@unaffiliated/matthiaskrgr] has quit [Ping timeout: 265 seconds]
20141115 19:00:16-!- janebot_ [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Ping timeout: 265 seconds]
20141115 19:00:20-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 265 seconds]
20141115 19:00:50-!- matthiaskrgr [matthiaskr@I.Eat.Babies.PanicBNC.nl] has joined #wesnoth-dev
20141115 19:01:21-!- matthiaskrgr is now known as Guest54467
20141115 19:03:07-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
20141115 19:03:11-!- _trewe [~trewe@2.81.9.175] has joined #wesnoth-dev
20141115 19:03:30-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 19:05:51-!- trewe [~trewe@188.251.24.225] has quit [Ping timeout: 265 seconds]
20141115 19:13:49-!- Sulfur [~Miranda@p5B008990.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141115 19:17:21-!- trewe [~trewe@188.250.137.191] has joined #wesnoth-dev
20141115 19:17:35-!- Guest54467 [matthiaskr@I.Eat.Babies.PanicBNC.nl] has quit [Changing host]
20141115 19:17:35-!- Guest54467 [matthiaskr@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20141115 19:17:47-!- _trewe [~trewe@2.81.9.175] has quit [Ping timeout: 245 seconds]
20141115 19:17:50-!- Guest54467 is now known as matthiaskrgr_
20141115 19:18:19-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
20141115 19:19:24-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has joined #wesnoth-dev
20141115 19:19:24-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has quit [Changing host]
20141115 19:19:24-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141115 19:20:07-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 19:21:13-!- higgins [~higgins@192.241.198.49] has quit [Ping timeout: 255 seconds]
20141115 19:21:57< gfgtdf> iceiceice: online?
20141115 19:22:06-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 255 seconds]
20141115 19:22:07-!- noy_ is now known as noy
20141115 19:23:01-!- yarker [~bismilah@li629-190.members.linode.com] has quit [Ping timeout: 255 seconds]
20141115 19:25:18-!- yarker [~bismilah@li629-190.members.linode.com] has joined #wesnoth-dev
20141115 19:27:00-!- higgins [~higgins@192.241.198.49] has joined #wesnoth-dev
20141115 19:28:08-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has joined #wesnoth-dev
20141115 19:29:02-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has joined #wesnoth-dev
20141115 19:29:40-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20141115 19:33:46-!- Xudo_ [bce88790@gateway/web/freenode/ip.188.232.135.144] has quit [Ping timeout: 246 seconds]
20141115 19:41:42-!- janebot___ [~Gambot@grickit.us] has joined #wesnoth-dev
20141115 19:47:40-!- Netsplit *.net <-> *.split quits: yann, janebot__
20141115 19:54:15-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 19:56:13-!- Netsplit over, joins: yann
20141115 19:59:39-!- gfgtdf_ [~chatzilla@f054061241.adsl.alicedsl.de] has joined #wesnoth-dev
20141115 19:59:53-!- shadowm_desktop2 [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141115 20:00:00-!- Pepe___ [~ppjet@106.186.127.196] has joined #wesnoth-dev
20141115 20:00:17-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
20141115 20:00:22-!- ryao_ [~ryao@smtp.gentoo.org] has joined #wesnoth-dev
20141115 20:02:33-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 20:05:04-!- Netsplit *.net <-> *.split quits: gfgtdf, Pepe_, shadowm_desktop, irker791, ryao, iwaim
20141115 20:05:05-!- gfgtdf_ is now known as gfgtdf
20141115 20:06:36-!- Netsplit over, joins: iwaim
20141115 20:07:49-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141115 20:07:49-!- 16WAAI3BC [~chatzilla@f054061241.adsl.alicedsl.de] has joined #wesnoth-dev
20141115 20:07:49-!- irker791 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20141115 20:07:49-!- Pepe_ [~ppjet@anderith.bouah.net] has joined #wesnoth-dev
20141115 20:08:00-!- janebot___ [~Gambot@grickit.us] has quit [Ping timeout: 258 seconds]
20141115 20:08:07-!- janebot____ [~Gambot@grickit.us] has joined #wesnoth-dev
20141115 20:09:00-!- trewe [~trewe@188.250.137.191] has quit [Ping timeout: 250 seconds]
20141115 20:09:02-!- c74d [~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766] has quit [Remote host closed the connection]
20141115 20:09:41-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 244 seconds]
20141115 20:09:41-!- 16WAAI3BC [~chatzilla@f054061241.adsl.alicedsl.de] has quit [Ping timeout: 244 seconds]
20141115 20:09:41-!- Pepe_ [~ppjet@anderith.bouah.net] has quit [Ping timeout: 244 seconds]
20141115 20:10:18-!- oldlaptop [~quassel@50-108-67-218.adr01.mskg.mi.frontiernet.net] has quit [Ping timeout: 258 seconds]
20141115 20:11:06-!- shikadibot [~shikadi@wesnoth/umc-dev/bot/shikadibot] has quit [Ping timeout: 258 seconds]
20141115 20:11:11-!- shikadibot_ [~shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20141115 20:11:31-!- EliDupree [~quassel@66-189-34-122.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 258 seconds]
20141115 20:11:55-!- Pepe___ [~ppjet@106.186.127.196] has quit [Ping timeout: 258 seconds]
20141115 20:11:56-!- MaraJade [goossenm@osuosl/staff/MaraJade] has quit [Ping timeout: 258 seconds]
20141115 20:12:15-!- Pepe_ [~ppjet@anderith.bouah.net] has joined #wesnoth-dev
20141115 20:12:22-!- oldlaptop [~quassel@50-108-67-218.adr01.mskg.mi.frontiernet.net] has joined #wesnoth-dev
20141115 20:13:20-!- EliDupree [~quassel@66-189-34-122.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20141115 20:13:47-!- MaraJade [goossenm@osuosl/staff/MaraJade] has joined #wesnoth-dev
20141115 20:14:54-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has quit [Ping timeout: 258 seconds]
20141115 20:14:54-!- esr [~esr@wesnoth/developer/esr] has quit [Ping timeout: 258 seconds]
20141115 20:15:16-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has joined #wesnoth-dev
20141115 20:16:03-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has quit [Ping timeout: 258 seconds]
20141115 20:16:28-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141115 20:22:01-!- molgrum [~molgrum@212.85.89.43] has quit [Ping timeout: 258 seconds]
20141115 20:23:11-!- molgrum [~molgrum@212.85.89.43] has joined #wesnoth-dev
20141115 20:28:09-!- vifon1 [~vifon@bohdan.wu-be.de] has joined #wesnoth-dev
20141115 20:28:45-!- vifon [~vifon@bohdan.wu-be.de] has quit [Disconnected by services]
20141115 20:28:49-!- vifon1 is now known as vifon
20141115 20:29:06-!- c74d [~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766] has joined #wesnoth-dev
20141115 20:30:19-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20141115 20:30:19-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20141115 20:30:19-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20141115 20:30:22-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20141115 20:30:45-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 21:01:02-!- matthiaskrgr_ is now known as matthiaskrgr
20141115 21:02:47-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
20141115 21:03:55-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141115 21:05:32-!- ancestral [~ancestral@173-11-40-137-Minnesota.hfc.comcastbusiness.net] has joined #wesnoth-dev
20141115 21:07:00-!- ancestral_ [~ancestral@166.170.21.8] has joined #wesnoth-dev
20141115 21:10:32-!- ancestral [~ancestral@173-11-40-137-Minnesota.hfc.comcastbusiness.net] has quit [Ping timeout: 256 seconds]
20141115 21:10:33-!- ancestral_ is now known as ancestral
20141115 21:14:04-!- travis-ci [~travis-ci@ec2-54-237-176-169.compute-1.amazonaws.com] has joined #wesnoth-dev
20141115 21:14:04< travis-ci> gfgtdf/wesnoth-old#370 (remove_netwoek_controller - 8474594 : gfgtdf): The build has errored.
20141115 21:14:04< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/41113996
20141115 21:14:04-!- travis-ci [~travis-ci@ec2-54-237-176-169.compute-1.amazonaws.com] has left #wesnoth-dev []
20141115 21:26:25-!- bumbadadabum_ [~bumbadada@d155109.upc-d.chello.nl] has quit [Quit: Ik ga weg]
20141115 21:31:32-!- ancestral [~ancestral@166.170.21.8] has quit [Quit: Smell ya later!]
20141115 21:31:38-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141115 21:31:43-!- ancestral_ [~ancestral@63.92.240.233] has joined #wesnoth-dev
20141115 21:33:22-!- cib0 [~cib@p5DC75045.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20141115 21:43:59-!- kex [~kex@78.157.29.160] has quit [Remote host closed the connection]
20141115 21:54:59< ancestral_> Does anyone care about the wiki?
20141115 21:55:12< ancestral_> I thinking  largely, “no”
20141115 21:55:42-!- travis-ci [~travis-ci@ec2-54-198-229-181.compute-1.amazonaws.com] has joined #wesnoth-dev
20141115 21:55:42< travis-ci> gfgtdf/wesnoth-old#371 (remove_netwoek_controller - e5528ea : gfgtdf): The build passed.
20141115 21:55:42< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/41116659
20141115 21:55:42-!- travis-ci [~travis-ci@ec2-54-198-229-181.compute-1.amazonaws.com] has left #wesnoth-dev []
20141115 21:56:34< ancestral_> A wiki with broken pictures is useless
20141115 21:56:40-!- ancestral_ [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20141115 22:04:55-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has quit [Quit: Sűrű sötét az éj, dühöng a déli szél]
20141115 22:11:44-!- Ravana_ [SZ_Bot@27-83-235-80.dyn.estpak.ee] has quit [Ping timeout: 256 seconds]
20141115 22:12:01-!- SZ_Bot [SZ_Bot@27-83-235-80.dyn.estpak.ee] has joined #wesnoth-dev
20141115 22:12:08-!- SZ_Bot is now known as Ravana_
20141115 22:26:50-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has quit [Remote host closed the connection]
20141115 22:36:30-!- irker791 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20141115 22:40:22< mattsc> gfgtdf: what am I missing?  “wesnoth/src/server/server.cpp:2340:8: error: no previous prototype for function 'count_sides' [-Werror,-Wmissing-prototypes]”
20141115 22:41:46< gfgtdf> mattsc: hmm maybe adding 'static' to the function count_sides in server.cpp will help but i dont really know.
20141115 22:43:02< mattsc> gfgtdf: yes, if I do that, it does compile.
20141115 22:43:15< gfgtdf> mattsc: accoring to https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html missing-protitype is a warnign for C only not for c++
20141115 22:43:21< gfgtdf> warning*
20141115 22:44:37< Anakonda> and even then fixed by declaring it in the header
20141115 22:47:35< mattsc> gfgtdf: I don’t see anything in the build settings that look to me like Xcode is compiling wesnothd using C rather than C++
20141115 22:48:03< gfgtdf> mattsc: hm mabye the page is just unprecise, or that page is just aout gcc not about clang
20141115 22:48:18< mattsc> but then, read any of my previous disclaimers concerning C++, compilers, Xcode, Life, the Universe and Everything.
20141115 22:48:51< mattsc> *concerning my knowledge of …
20141115 22:48:51-!- un214 [~un214@2602:306:cccf:af99:56a0:50ff:fe57:101d] has joined #wesnoth-dev
20141115 22:50:04-!- irker334 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20141115 22:50:04< irker334> wesnoth: gfgtdf wesnoth:master b1160fe45159 / src/server/server.cpp: add static to a local function. http://git.io/BSAy4A
20141115 22:50:15< gfgtdf> mattsc: i made a commit ^
20141115 22:51:34< mattsc> gfgtdf: thanks - will pull and build in a moment (waiting for something else to finish first)
20141115 22:51:41-!- travis-ci [~travis-ci@ec2-54-198-173-134.compute-1.amazonaws.com] has joined #wesnoth-dev
20141115 22:51:41< travis-ci> gfgtdf/wesnoth-old#373 (wesnothd_sides - 1eb7fee : gfgtdf): The build has errored.
20141115 22:51:41< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/41120678
20141115 22:51:41-!- travis-ci [~travis-ci@ec2-54-198-173-134.compute-1.amazonaws.com] has left #wesnoth-dev []
20141115 22:53:06< gfgtdf> i take that as a "passed"
20141115 22:55:05-!- un214 [~un214@2602:306:cccf:af99:56a0:50ff:fe57:101d] has quit [Remote host closed the connection]
20141115 22:56:13< irker334> wesnoth: mattsc wesnoth:master 7c71f81ed0ea / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update Xcode project file http://git.io/J3yiRw
20141115 22:56:18-!- gfgtdf_ [~chatzilla@d148144.adsl.hansenet.de] has joined #wesnoth-dev
20141115 22:56:37< mattsc> gfgtdf: yep, all good again, thanks.
20141115 22:57:03< gfgtdf_> (the travis message i mean)
20141115 22:57:10< gfgtdf_> mattsc: ok ty
20141115 22:57:17< mattsc> gfgtdf_: (yes, I understood)
20141115 22:58:42-!- gfgtdf [~chatzilla@f054061241.adsl.alicedsl.de] has quit [Ping timeout: 264 seconds]
20141115 22:58:44-!- gfgtdf_ is now known as gfgtdf
20141115 23:08:48-!- janebot____ is now known as janebot
20141115 23:09:15-!- janebot [~Gambot@grickit.us] has quit [Changing host]
20141115 23:09:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20141115 23:18:08-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20141115 23:18:25< iceiceice> gfgtdf: did you test that nothing crashes if you give a game with > 9 sides?
20141115 23:21:00< iceiceice> gfgtdf: it looks like it might because fo this: https://github.com/wesnoth/wesnoth/blob/master/src/map.cpp#L209
20141115 23:21:45< iceiceice> gfgtdf: i don't think you should delete checks like this on the server unless you are sure of such things,
20141115 23:21:58< iceiceice> it's always much better to tell them "sorry such and such is not allowed" than to crash later
20141115 23:25:29< iceiceice> (i refer to this commit message https://github.com/wesnoth/wesnoth/commit/7a1d1a7a3a2318a32cd25499bd68343048537835)
20141115 23:27:00-!- travis-ci [~travis-ci@ec2-54-198-173-134.compute-1.amazonaws.com] has joined #wesnoth-dev
20141115 23:27:01< travis-ci> gfgtdf/wesnoth-old#374 (wesnothd_sides - 7a1d1a7 : gfgtdf): The build passed.
20141115 23:27:01< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/41120832
20141115 23:27:01-!- travis-ci [~travis-ci@ec2-54-198-173-134.compute-1.amazonaws.com] has left #wesnoth-dev []
20141115 23:30:56-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has quit [Ping timeout: 250 seconds]
20141115 23:32:24-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141115 23:34:05-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has joined #wesnoth-dev
20141115 23:34:59-!- Anakonda [Anakonda@87-92-139-179.bb.dnainternet.fi] has quit [Read error: Connection reset by peer]
20141115 23:37:18-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 258 seconds]
20141115 23:45:43< gfgtdf> iceiceice: the comment in map.cpp is onyl about teh map format, completely unrelated to the server i think.
20141115 23:46:20< iceiceice> gfgtdf: but its all related,
20141115 23:46:22< gfgtdf> iceiceice: its not liek the server parses the map at some point
20141115 23:46:28< iceiceice> in the sense that, if i host a game and wait aroudn for poeple to join,
20141115 23:46:36< iceiceice> and then finally it fills with 10+ people
20141115 23:46:41< iceiceice> then i click start
20141115 23:46:44< iceiceice> and everyone crashes to title screen
20141115 23:46:48< iceiceice> that's a bug
20141115 23:46:59< gfgtdf> iceiceice: then it a client bug an unrelated to the server
20141115 23:47:05< iceiceice> no, the server should reject such games
20141115 23:47:14< iceiceice> if the client does not support them
20141115 23:47:31< iceiceice> and currently we don't support them
20141115 23:47:32< gfgtdf> iceiceice: also in sp we can alredy have 10+ sides
20141115 23:47:44< gfgtdf> iceiceice: so the game engine can definitely hande it
20141115 23:47:53< iceiceice> ok, i think it should be lifted everywhere ant once though
20141115 23:48:07< iceiceice> on the server, the purpose is definitely so that people don't get screwed in the way i describe
20141115 23:48:51< iceiceice> maybe you think the check should be on mp create instead of in mp server?
20141115 23:48:54< gfgtdf> iceiceice: this code here also uses MAX_PLAYERs https://github.com/wesnoth/wesnoth/blob/113c8d8504cc0432b4ba063ae076e9a0107477d3/src/game_initialization/multiplayer_connect.cpp#L413
20141115 23:49:13< gfgtdf> iceiceice: i didnt look at the code yez
20141115 23:49:15< gfgtdf> yet*
20141115 23:49:32< gfgtdf> iceiceice: well teh main purpose it that teh server doesnt crash
20141115 23:49:50< gfgtdf> iceiceice: becaseu of some index out of range bug
20141115 23:49:54< iceiceice> y i guess you are right because server had fixed size arrays
20141115 23:50:06< gfgtdf> iceiceice: no teh server always used std::vector
20141115 23:50:23< iceiceice> y but sized to a constant
20141115 23:50:40< gfgtdf> y
20141115 23:52:14< gfgtdf> iceiceice: hm it seems leik mp_connect migth indeed have soem problems with color
20141115 23:52:31< gfgtdf> iceiceice: shoudl be easy to fix thought, and it not even guranteed taht teh uiser wil notice
20141115 23:54:36< gfgtdf> iceiceice: another thing
20141115 23:54:56< gfgtdf> iceiceice: it looks like wesnothd::game::load_next_scenario checnges the level_
20141115 23:55:05< gfgtdf> iceiceice: e.g rewrites history
20141115 23:55:14< iceiceice> gfgtdf: yeah
20141115 23:55:23< iceiceice> its bad because i think it doesn't save replays of the first scenario
20141115 23:55:33< iceiceice> since htat happens in game dtor iirc
20141115 23:55:36< gfgtdf> iceiceice: wouldnt that cause OOS for observers ?
20141115 23:56:28< gfgtdf> iceiceice: since they have wrong controller info
20141115 23:56:28< iceiceice> i have to check i'm not sure
20141115 23:57:55< iceiceice> gfgtdf: i don't know if i ever tested the case when
20141115 23:58:02< iceiceice> an observer starts watching a campaign in the middle
--- Log closed Sun Nov 16 00:00:04 2014