--- Log opened Thu Apr 03 00:00:01 2014
--- Day changed Thu Apr 03 2014
20140403 00:00:00-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140403 00:00:29< gfgtdf> shadowm: can you tell me when you reupped teh 1.13.0-dev server ?
20140403 00:00:45< shadowm> Oh right, I can do that right now since it's nine o'clock already.
20140403 00:01:33< gfgtdf> shadowm: is that dependent or your local time ?
20140403 00:01:37-!- spoffy [~spoffy@host-80-47-182-18.as13285.net] has quit [Read error: Operation timed out]
20140403 00:01:56< gfgtdf> i mean if it was 8:00 you coudn't do it ?
20140403 00:01:58< shadowm> No, it's only dependent in that the git update on the server takes place every hour at zero minutes.
20140403 00:02:18< shadowm> And I don't have the means to force an update any other time, so yeah.
20140403 00:02:55< gfgtdf> shadowm: so that all goes automaticly ?
20140403 00:03:16< shadowm> Not the rebuild, only the git pull. Rebuilds must be done by hand.
20140403 00:04:30< shadowm> gfgtdf: trunk server rebuilt and restarted.
20140403 00:05:04< shadowm> Uh.
20140403 00:05:06< gfgtdf> :) i'll test imideately
20140403 00:05:11< shadowm> I don't remember registering a 'shadowm3' nickname...
20140403 00:05:29< shadowm> Hm, okay, it's me, all right.
20140403 00:05:55< gfgtdf> why do you need 3 nicknames to compile teh server ?
20140403 00:06:08< gfgtdf> i see you
20140403 00:06:11< gfgtdf> on teh server
20140403 00:06:13< shadowm> Not to compile, only to join without entering a password.
20140403 00:07:15< shadowm> Okay, it seems the server didn't quite restart like I wanted, it's the previous build.
20140403 00:08:12< shadowm> gfgtdf: It's still the old build for some reason, let me restart it by hand.
20140403 00:08:50< gfgtdf> shadowm: realy? it work well for me
20140403 00:09:13< shadowm> /version in the lobby gives "1.13.0-dev (e1bbfc4-Clean)".
20140403 00:09:35< shadowm> It should be 3acb4f, not e1bbfc4.
20140403 00:10:20< shadowm> Hm. Wait.
20140403 00:10:32< shadowm> I'm confused, the binary is the correct one.
20140403 00:12:29< shadowm> gfgtdf: Okay, I'm not sure what happened, but if you say it's okay then it's okay I guess.
20140403 00:13:05< shadowm> iceiceice: Are you aware that the Enter blindfolded checkbox causes the Preferences button in the lobby to overlap the Quit button at 800x600?
20140403 00:13:14< iceiceice> no...
20140403 00:13:15< iceiceice> sorry
20140403 00:13:29< iceiceice> is there an appropriate fix that is obvious to you?
20140403 00:13:57< iceiceice> currently the way the positioning works is that Quick replays is placed half way between preference and the thing to the left i guess
20140403 00:14:01< iceiceice> let me review actually
20140403 00:14:24< shadowm> iceiceice: https://dl.dropboxusercontent.com/u/21371130/screenshots/lobby-800x600.png (You can pass `-w -r 800x600` in the command line to force starting windowed at 800x600, by the way, but the minimum resolution we are supposed to support is actually 800x480.)
20140403 00:14:28< gfgtdf> iceiceice: did you or anyone else fix teh maditory child missing bug when relaoding a serversave ?
20140403 00:14:59< iceiceice> gfgtdf: i somewhat doubt that it is possible to load server saves right now
20140403 00:15:22< gfgtdf> ok
20140403 00:15:32< iceiceice> i think that there is new code that decides how to load multiplayer games, and i dont think the server has gotten a correspodning patch
20140403 00:15:44< iceiceice> anyways the old setup was pretty much a hack i think
20140403 00:16:08< iceiceice> i would like to tinker with this soon
20140403 00:16:43< shadowm> iceiceice: It's a little too cramped atm for such low resolutions, so I don't have a suggestion atm, sorry.
20140403 00:17:09< iceiceice> so the idea we had at one point is that since enter blindfold actually forces "quick replays" to true,
20140403 00:17:17< iceiceice> it mgiht be best to have a drop down menu
20140403 00:17:29< iceiceice> but i'm also told we don't have a gui2 version of that?
20140403 00:17:50< shadowm> I find having to support < 1024x768 to be very limiting in this era, but Ivanovic absolutely needs his OpenPandora builds (the Pandora only does up to 800x480).
20140403 00:18:27< shadowm> iceiceice: The defaultl obby is GUI1. The GUI2 lobby is currently disabled by default and hidden behind the "Experimental lobby" option in Preferences → Advanced.
20140403 00:18:35< iceiceice> i see
20140403 00:18:57< shadowm> GUI1 does have a combobox, which is most notably used for MP game setup, and the compressed saves advanced preferences entry.
20140403 00:18:59< iceiceice> so i could reuse the drop down menu from the multiplayer connect dialog if i want?
20140403 00:19:08< iceiceice> ok i think i will patch that then
20140403 00:19:20< iceiceice> if you like you can assign it as a bug to me so i dont forget
20140403 00:20:55-!- Ivanovic [~ivanovic@x2f47f8e.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20140403 00:23:28-!- Ivanovic [~ivanovic@x2f4e696.dyn.telefonica.de] has joined #wesnoth-dev
20140403 00:24:50< shadowm> iceiceice: Done: https://gna.org/bugs/index.php?21888
20140403 00:25:39< iceiceice> oh shadowm: if you have access to one of these tiny resolutions,
20140403 00:25:47< iceiceice> maybe you should review sachith's proposal
20140403 00:26:04< mattsc> crimson_penguin: Crap, I’m just such an idiot.  I might just have figured out what I was doing wrong all along - but I am not going to tell you because it’s too embarrassing.
20140403 00:26:16< shadowm> iceiceice: As I said it's just a matter of passing the right switches in the command line (`-w -r 800x480`).
20140403 00:26:18< iceiceice> i tested the earlier version and it looks good, but i dont know if it will work on the tiny resolutions
20140403 00:26:19< mattsc> I’ll check back into that later tonight.
20140403 00:26:23< iceiceice> i see
20140403 00:27:09< shadowm> What would his proposal be?
20140403 00:28:10< iceiceice> https://github.com/wesnoth/wesnoth/pull/136
20140403 00:29:36< shadowm> Statistics. Maths. I can't help review that. :p
20140403 00:30:20< shadowm> Someone should tell him to update players_changelog too. I'll take a look at the GUI aspect later anyway,
20140403 00:33:35< gfgtdf> shadowm: should i add bugfixes to the changelog ?
20140403 00:33:59< iceiceice> if it is reported then i guess so
20140403 00:34:09< iceiceice> if its a bug you are fixing from a previous commit that no one has noticed then probl ynot
20140403 00:34:17< iceiceice> idk thats what i've been doing
20140403 00:34:50< shadowm> gfgtdf: Always.
20140403 00:35:22< gfgtdf> shadowm: and what should i do if i dont know wherer i fixed a bug ?
20140403 00:35:23< shadowm> gfgtdf: But not necessarily always to players_changelog -- that one is only for user-visible stuff.
20140403 00:35:41< gfgtdf> shadowm: are wml developers users ?
20140403 00:35:55< shadowm> gfgtdf: Err on the side of caution and mention the change too so that people can have an idea of what might have caused some new bug they are experiencing.
20140403 00:36:09< shadowm> Notice that that's why I mentioned the mixer configuration changes in the changelog for 1.11.12.
20140403 00:37:11< gfgtdf> shadowm: should i add somethign about https://gna.org/bugs/index.php?20895
20140403 00:37:15< shadowm> gfgtdf: No, WML features don't go in players_changelog.
20140403 00:37:24< shadowm> *features/changes/fixes
20140403 00:37:52< shadowm> Unless the effect is too evident.
20140403 00:38:36< shadowm> For example, a player has no idea whether fixing the [unit_type] alignment tag so it's actually interpreted by the engine changes anything.
20140403 00:39:04< shadowm> However, the effect of the fix is that the previous situation where all units were neutral is now fixed visibly for players in all scenarios.
20140403 00:39:38< shadowm> This is not a hypothetical example -- a bug like that actually happened once and it actually made it into a development release.
20140403 00:40:18< shadowm> 1.8 beta 7. ¬_¬
20140403 00:40:57< gfgtdf> do you expect 7 betas again this time?
20140403 00:41:03< shadowm> gfgtdf: #20895 doesn't sound players_changelog-worthy.
20140403 00:41:25< gfgtdf> 	shadowm: no genera worthy becasue i dont know wether i fixed that
20140403 00:41:33< gfgtdf> general*
20140403 00:42:00< gfgtdf> (i wote a comment in that thread)
20140403 00:42:03< shadowm> Yeah, it should go in the main changelog even if the fix isn't confirmed yet.
20140403 00:42:03< gfgtdf> wrote
20140403 00:42:36< shadowm> Of course, it helps to make sure somebody (player or dev) can confirm the fix before the release. ;)
20140403 00:43:27< shadowm> gfgtdf: April already started and Ivanovic wanted to release 1.12.0 on May, so I doubt there's time for more than a couple more betas.
20140403 00:43:51-!- stikonas__ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140403 00:44:01-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20140403 00:44:07< shadowm> Unless the general consensus is that the 1.12 branch is still too broken, of course. One could assume that from the current open bug count...
20140403 00:44:38< shadowm> Back in my days the bug count was always below 200.
20140403 00:44:59< iceiceice> well maybe you should come out of retirement and show us how its done then :p
20140403 00:45:44< shadowm> I have tried hunting for bugs I can fix before and I already did all I could for 1.11.x.
20140403 00:47:19< iceiceice> ok serious question, if i actually do this combo box change, i have to find a string already committed which can server as the "Default" option right?
20140403 00:47:25< iceiceice> *server
20140403 00:47:26< iceiceice> *serve
20140403 00:48:18< shadowm> iceiceice: That or convince Ivanovic to give you free pass for adding a hopefully-negligible number of new strings.
20140403 00:48:39< iceiceice> is there a good way to see a list of what strings are available?
20140403 00:48:47< shadowm> I'm sure you can convince him if you pose the Pandora situation as an argument.
20140403 00:49:27< shadowm> iceiceice: Well... you can grep po/*/*.pot for the strings you need, although they may be line-wrapped.
20140403 00:49:45< shadowm> You can also `grep -R data/ src/`.
20140403 00:50:45< shadowm> `fgrep msgid po/*/*.pot` would certainly give you a full list of all strings in all textdomains (except for those strings that are line-wrapped).
20140403 00:50:55< gfgtdf> 	shadowm: we are in a string freeze a i cannot add new string to the game ?
20140403 00:51:37< shadowm> iceiceice: For what you are doing, though, you probably can only use strings from wesnoth or wesnoth-lib depending on whether the GETTEXT_DOMAIN preprocessor symbol is defined for the cpp file, and what it contains (if omitted, the wesnoth textdomain is the default).
20140403 00:52:09< iceiceice> i was thinking even that i might use the string "Default" used in the context of "Default Era" 
20140403 00:52:23< iceiceice> i'm not sure if that gets translated with a funny connotation i dont want thoguh
20140403 00:52:33< shadowm> gfgtdf: Nope, only existing strings can be used in 1.12. Moving (within the same textdomain) or removing strings is also a thing that can be done.
20140403 00:52:43< iceiceice> its in wesnoth-multiplayer
20140403 00:52:49< iceiceice> so maybe available to lobby?
20140403 00:52:57< shadowm> If you need to fix a typo in a translatable string in 1.12 the process is a little more complicated.
20140403 00:53:16< iceiceice> gfgtdf: what strings are you adding? i guess for error messages they dont need to be translated anyways
20140403 00:53:34< iceiceice> a warning is different thoguh i guess
20140403 00:53:53< gfgtdf> iceiceice	: no it's not about the warning, since they are in english always
20140403 00:53:54< shadowm> iceiceice: I believe wesnoth-multiplayer is a WML textdomain.
20140403 00:54:07< iceiceice> oh
20140403 00:54:32< shadowm> It looks like src/multiplayer*.cpp don't define GETTEXT_DOMAIN, so the strings from there are in the wesnoth textdomain.
20140403 00:54:39< gfgtdf> iceiceice: it was about the string "Enables the deterministic mode, where you'll get the same random results when you reload a game." from b4847d95e75cf4420f3ea3256fccfc4cac271439
20140403 00:55:05< shadowm> Unfortunately, the only 'Default' in the wesnoth textdomain is 'theme^Default'.
20140403 00:55:12< iceiceice> yeah i see
20140403 00:55:34< iceiceice> i'm going to look at some of these other combo boxes i guess
20140403 00:58:18< shadowm> iceiceice: As far as I can see 21:39:25 <Gambit> http://i.imgur.com/aLBTkR1.jpg
20140403 00:58:24< shadowm> Ooooops.
20140403 00:58:32< Gambit> lol good job
20140403 00:58:41< Gambit> That looks great without any context.
20140403 00:58:45< shadowm> gfgtdf: As far as I can see, b4847d95e75cf4420f3ea3256fccfc4cac271439 is a _feature_.
20140403 00:58:45< iceiceice> lol
20140403 00:58:59< gfgtdf> 	shadowm: yes it is
20140403 00:59:01< shadowm> That means it doesn't belong in the 1.12 branch.
20140403 00:59:12< shadowm> gfgtdf: It also has UI strings that don't have the translatability mark.
20140403 00:59:28< gfgtdf> shadowm: ye i know i forgot teh translateable mark
20140403 00:59:41< shadowm> 1.13.x (master) isn't in string freeze, so you can do whatever you want there.
20140403 01:02:42-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 01:02:53< gfgtdf> shadowm: ye i know i just wanted to know wether such a string would be reson enough not to put something into beta.
20140403 01:03:03-!- Ivanovic_ [~ivanovic@x2f460d0.dyn.telefonica.de] has joined #wesnoth-dev
20140403 01:03:06-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20140403 01:03:32< shadowm> It would.
20140403 01:03:49< shadowm> But in this case, the string addition would be overshadowed by the, uh, feature.
20140403 01:03:52< gfgtdf> shadowm: we use the same server for 1.11.12 and 1.11.12+dev ?
20140403 01:04:06< shadowm> No, 1.11.12+dev uses the trunk server.
20140403 01:04:17< gfgtdf> the one for 1.13-dev ?
20140403 01:04:27< shadowm> Yeah.
20140403 01:04:37< shadowm> ... Maybe it's time to change that, actually. Not sure.
20140403 01:05:26-!- Ivanovic [~ivanovic@x2f4e696.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20140403 01:06:58-!- Ivanovic_ is now known as Ivanovic
20140403 01:07:06< iceiceice> hmm i think i may just recycle the "Show Replay" string from the load dialog
20140403 01:07:10< iceiceice> it is in wesnoth-lib
20140403 01:07:23< iceiceice> so the options would be "Show Replay" "Quick Replay" and "Enter Blindfolded"
20140403 01:07:52< shadowm> We don't have a way to transplant translations between textdomains, I believe.
20140403 01:08:07< iceiceice> i thought we thought wesnoth-lib is permitted in the lobby?
20140403 01:08:29< shadowm> I said above that src/multiplayer* uses wesnoth, not wesnoth-lib.
20140403 01:08:52-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 01:09:32< shadowm> And the GUI1 lobby comes from src/multiplayer* AFAIK.
20140403 01:10:27< iceiceice> hmm
20140403 01:10:41< iceiceice> can we add an additional domain to the lobby? or is that bad
20140403 01:11:12-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20140403 01:11:32< shadowm> At this point? :|
20140403 01:11:43< shadowm> It's the same as breaking the string freeze.
20140403 01:12:06< shadowm> It'd only be far more sophisticated than the norm.
20140403 01:12:32< shadowm> Not to mention that adding a textdomain requires some WML and build system bureaucracy.
20140403 01:12:44< iceiceice> i thought string freeze is bad because it makes unexpected work for translators
20140403 01:12:47< iceiceice> i see
20140403 01:13:03< shadowm> No, the string freeze is good for translators. Breaking it is bad.
20140403 01:13:10< iceiceice> that's what i meant
20140403 01:13:50< iceiceice> well i might just leave the default option blank then, i dont think anyone would be too confused by that
20140403 01:13:56< shadowm> I personally prefer a more pragmatic approach to this kind of thing, instead of hard-and-fast rules, but it's (fortunately) not my call.
20140403 01:14:14< iceiceice> if someone complains we can contemplate other alternatives
20140403 01:14:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140403 01:14:18< shadowm> Eh, I don't think naked buttons are acceptable.
20140403 01:14:36-!- stikonas__ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20140403 01:14:42< shadowm> It means that you will be tempted to click on it (and face the possible consequences) to figure out what the deal with it is.
20140403 01:14:55< iceiceice> its just a combobox thoguh
20140403 01:15:14< shadowm> That will either result in a bug report, or relegating your feature to obscurity.
20140403 01:15:27< shadowm> And GUI1 comboboxes look the same as GUI1 command buttons until clicked on.
20140403 01:16:01< shadowm> Personally, I would try to obtain an exemption.
20140403 01:16:26< iceiceice> ok, well i'll try to get a patch in anyways and then we'll work out an exception after
20140403 01:16:34< iceiceice> if possible
20140403 01:16:57< shadowm> Sure, as long as you don't wait until the next pot-update to ask.
20140403 01:17:27< iceiceice> it's too bad that there's no way to transplant strings in text domains
20140403 01:17:29< shadowm> Otherwise you may get a "nice" message from Ivanovic asking you to revert the addition of the string. But who am I kidding at this point, he will read all these messages.
20140403 01:17:34< iceiceice> that seems like something someone would often want to do
20140403 01:17:58< iceiceice> if we already got everyone to translate it once anyways
20140403 01:19:37< iceiceice> surely there are some strings that occur in multiple domains?
20140403 01:19:39< iceiceice> how is that handled?
20140403 01:19:44< iceiceice> the translators just have to do it multiple times?
20140403 01:20:08-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 01:21:00< iceiceice> maybe i will make a feature request :)
20140403 01:21:02< iceiceice> bb for now
20140403 01:21:04-!- iceiceice [~chris@207-237-132-90.ny.subnet.cable.rcn.com] has quit [Quit: Leaving]
20140403 01:21:23-!- Ivanovic [~ivanovic@x2f460d0.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20140403 01:21:46-!- Kexoth [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140403 01:22:01-!- gfgtdf [~chatzilla@f054062163.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20140403 01:22:10-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 01:22:30-!- Kexoth [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140403 01:23:06-!- gfgtdf [~chatzilla@f054059140.adsl.alicedsl.de] has joined #wesnoth-dev
20140403 01:25:00-!- Ivanovic [~ivanovic@x2f4ce4f.dyn.telefonica.de] has joined #wesnoth-dev
20140403 01:27:11-!- wesbot changed the topic of #wesnoth-dev to: string+feature freeze active on 1.12 | 236 bugs, 352 feature requests, 28 patches | Logs: http://irclogs.wesnoth.org | Alternate logs: http://wesnoth.debian.net | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20140403 01:30:04-!- Ivanovic_ [~ivanovic@x2f47388.dyn.telefonica.de] has joined #wesnoth-dev
20140403 01:32:38-!- Ivanovic [~ivanovic@x2f4ce4f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20140403 01:33:57-!- Ivanovic_ is now known as Ivanovic
20140403 01:47:08< shadowm> 22:19:44 <iceiceice> the translators just have to do it multiple times?
20140403 01:47:32< shadowm> iceiceice: Pretty much, although of course they can take a look at the previous translation for reference.
20140403 01:50:49-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has joined #wesnoth-dev
20140403 01:56:43< mattsc> Is it normal that libboost_thread.dylib now depends on (includes) libboost_system.dylib ?
20140403 01:57:16-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140403 02:01:15< mattsc> … and yes, that was the last little piece missing in the puzzle
20140403 02:01:26< mattsc> crimson_penguin: got it to work.  Phew.
20140403 02:02:07-!- gfgtdf [~chatzilla@f054059140.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517]]
20140403 02:11:09-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20140403 02:14:49< mattsc> AI0867: that also means that things now work in Xcode with the change you made, so you can trash the work-around patch.
20140403 02:19:27-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20140403 02:22:41-!- sachith500 [~kvirc@112.134.227.224] has joined #wesnoth-dev
20140403 02:25:10-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Quit: Ik ga weg]
20140403 02:28:08-!- RiftWalker [~nathan@129.59.115.25] has quit [Ping timeout: 240 seconds]
20140403 02:28:47-!- sachith500 [~kvirc@112.134.227.224] has quit [Read error: Connection reset by peer]
20140403 02:29:17-!- sachith500 [~kvirc@112.134.227.224] has joined #wesnoth-dev
20140403 02:29:51-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 02:32:27-!- Kexoth [~kex@89.205.75.19] has quit [Read error: Operation timed out]
20140403 02:41:36-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 265 seconds]
20140403 02:42:05-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140403 02:42:41-!- RiftWalker [~nathan@129.59.115.25] has joined #wesnoth-dev
20140403 02:52:40-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 02:53:30-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20140403 02:53:36-!- esr [~esr@wesnoth/developer/esr] has quit [Ping timeout: 255 seconds]
20140403 02:53:53-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20140403 02:53:53-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20140403 02:53:53-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20140403 02:53:54-!- sachith500 [~kvirc@112.134.227.224] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140403 02:55:38-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has quit [Ping timeout: 240 seconds]
20140403 02:56:27-!- Ivanovic_ [~ivanovic@x2f4baa8.dyn.telefonica.de] has joined #wesnoth-dev
20140403 02:57:29-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20140403 02:59:39-!- Ivanovic [~ivanovic@x2f47388.dyn.telefonica.de] has quit [Ping timeout: 268 seconds]
20140403 03:00:21-!- Ivanovic_ is now known as Ivanovic
20140403 03:06:50-!- RustyShackleford [~Kryten@mo-184-6-82-162.dhcp.embarqhsd.net] has joined #wesnoth-dev
20140403 03:08:36-!- iwaim [~iwaim@2001:2c0:40e:2002:0:4:14:80] has joined #wesnoth-dev
20140403 03:20:12-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 03:21:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140403 03:23:02-!- Ivanovic_ [~ivanovic@x2f47313.dyn.telefonica.de] has joined #wesnoth-dev
20140403 03:23:08-!- Ivanovic [~ivanovic@x2f4baa8.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20140403 03:24:56-!- Ivanovic_ is now known as Ivanovic
20140403 03:26:03< iceiceice> hi:
20140403 03:26:06< iceiceice> is there any legal way to do this:
20140403 03:26:10< iceiceice> `const static char *replay_options_cstrings_[] = {_("Normal"), _("Quick replays"), _("Enter blindfolded")};`
20140403 03:26:12< iceiceice> or should i just give up
20140403 03:26:24< iceiceice> and do a different approach
20140403 03:29:40-!- RustyShackleford [~Kryten@mo-184-6-82-162.dhcp.embarqhsd.net] has quit []
20140403 03:33:36-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140403 03:41:42-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 03:43:24-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20140403 03:45:12-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 03:53:39-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140403 04:18:03-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 04:22:18-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 240 seconds]
20140403 04:33:44< shadowm> iceiceice: That should work. How does it not?
20140403 04:34:54< shadowm> iceiceice: Oh yeah, you want to use N_() and invoke the gettext function you need later down the road in a non-static-const context.
20140403 04:35:17< iceiceice> it doesn't matter, it's ancient history now
20140403 04:35:19< shadowm> N_() marks the string for grabbing by xgettext (generates .pot files by scanning the source), but it's actually a no-op.
20140403 04:35:21< iceiceice> but i was getting this: In file included from src/multiplayer_lobby.cpp:27:
20140403 04:35:21< iceiceice> src/multiplayer_lobby.hpp:211:50: error: use of undeclared identifier '_'
20140403 04:35:21< iceiceice> const static char *replay_options_cstrings_[] = {_("Normal"), _("Quick replays"), _("Enter...
20140403 04:35:47< shadowm> You may mark static const strings for translating but not call _() (a gettext function instead of a noop).
20140403 04:36:09< shadowm> If you do the call, you'll only get the translated version once, and the string will never be retranslated if the user changes language during the session.
20140403 04:36:23< iceiceice> ok, i think the solution i have now is better then
20140403 04:36:53< shadowm> N_() and _() are macros from src/gettext.hpp, so you need to include that.
20140403 04:37:16< shadowm> iceiceice: Hm, but the code you pasted uses _().
20140403 04:37:51< iceiceice> yeah thats like hours ago :)
20140403 04:38:53< shadowm> A more concrete example if you ever want to use that pattern again can be found in src/unit_types.cpp.
20140403 04:38:57< shadowm> src/unit_types.cpp:841: static const char* aligns[] = { N_("lawful"), N_("neutral"), N_("chaotic"), N_("liminal") };
20140403 04:39:10< iceiceice> ok thanks
20140403 04:39:30< shadowm> Later in the same function, an actual call to gettext is done for the return value.
20140403 04:40:01< shadowm> This allows to keep the code simple without breaking language switching.
20140403 04:40:02-!- Xenius__ [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140403 04:41:23-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has quit [Read error: Operation timed out]
20140403 04:52:03-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 05:00:20-!- cib0 [~cib@p5DD215E8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140403 05:02:48-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Ciao]
20140403 05:03:00-!- irker970 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140403 05:22:47-!- EdB [~edb@85.69.242.6] has joined #wesnoth-dev
20140403 05:23:13-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 05:27:50-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 252 seconds]
20140403 05:46:38-!- RiftWalker [~nathan@129.59.115.25] has quit [Ping timeout: 240 seconds]
20140403 05:49:25-!- EdB [~edb@85.69.242.6] has quit [Quit: Konversation terminated!]
20140403 06:14:14-!- RiftWalker [~nathan@129.59.115.25] has joined #wesnoth-dev
20140403 06:24:13< AI0867> mordante: zero. it's a hardware problem
20140403 06:27:34-!- mjs-de [~mjs-de@f049100161.adsl.alicedsl.de] has joined #wesnoth-dev
20140403 06:31:12< iceiceice> gfgtdf: after your most recent commits, skipped replays has stopped working
20140403 06:31:29< iceiceice> i find that it works fine at checkout a928ce76de33c58cf35082e422358ec690e48e25, but not at master
20140403 06:31:49-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140403 06:32:03-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 06:34:01-!- cib0 [~cib@p5DD215E8.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20140403 06:43:51-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has joined #wesnoth-dev
20140403 06:49:51-!- Gallaecio [~quassel@84.120.115.132.dyn.user.ono.com] has quit [Remote host closed the connection]
20140403 06:51:09-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140403 06:55:28-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 252 seconds]
20140403 06:57:17-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140403 06:58:30< iceiceice> shadowm: well i can't totally test it but i'm going to commit a proposed fix to use the combo thing
20140403 06:59:21< iceiceice> my guess is that if gfgtdf figures out about skip replays in his PR then it will work again
20140403 07:02:30-!- irker431 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140403 07:02:30< irker431> wesnoth: Chris Beck wesnoth:master e6a852f4a457 / src/ (multiplayer_lobby.cpp multiplayer_lobby.hpp): use a single combo for quick replays / blindfold in mp lobby http://git.io/kttZxw
20140403 07:08:10-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 268 seconds]
20140403 07:26:18-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140403 07:27:12-!- wesbot changed the topic of #wesnoth-dev to: string+feature freeze active on 1.12 | 237 bugs, 352 feature requests, 28 patches | Logs: http://irclogs.wesnoth.org | Alternate logs: http://wesnoth.debian.net | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20140403 07:28:46-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20140403 07:29:40< irker431> wesnoth: Chris Beck wesnoth:1.12 cfc82cfdbacc / src/ (multiplayer_lobby.cpp multiplayer_lobby.hpp): use a single combo for quick replays / blindfold in mp lobby http://git.io/z-cN0Q
20140403 07:29:42< irker431> wesnoth: Chris Beck wesnoth:1.12 167254e95177 / changelog players_changelog: update changelogs http://git.io/6pM2Qg
20140403 07:30:43< irker431> wesnoth: Chris Beck wesnoth:master c9321455b252 / changelog players_changelog: update changelogs http://git.io/_9cXIQ
20140403 07:35:11< iceiceice> Ivanovic: shadowm pointed out earlier today that changes i pushed a month ago (before feature freeze and 1.12 fork) caused the mp lobby to look bad in resolutions with <= 800 pixels width
20140403 07:35:54< iceiceice> the checkbox for the blindfold option was pushing the preferences button over underneath the quit button.
20140403 07:36:16< iceiceice> i have remedied this by using a dropdown menu for both quick replays and blindfold, which is something that had been discussed anyways
20140403 07:36:33< iceiceice> however i had to improvise a bit to get appropriate strings...
20140403 07:36:45< iceiceice> the strings i have right now (for the three possible options) are:
20140403 07:36:48< iceiceice> "Normal"
20140403 07:36:50< iceiceice> "Quick replays"
20140403 07:36:55< iceiceice> "Enter blindfolded"
20140403 07:38:50< iceiceice> This is perhaps not too confusing but it would really be much better to have something like "Normal replays", "Quick replays", "Blindfold replays", now that we have the new arrangement...
20140403 07:39:14< iceiceice> let me know how you feel about this and if it would be worth relaxing the string freeze in this case
20140403 07:41:03-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140403 07:43:01-!- cib0 [~cib@132.231.178.145] has joined #wesnoth-dev
20140403 07:47:09-!- mjs-de [~mjs-de@f049100161.adsl.alicedsl.de] has quit [Remote host closed the connection]
20140403 08:10:49-!- Octalot [~noct@27.74.208.46.dyn.plus.net] has joined #wesnoth-dev
20140403 08:17:51-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginmedia.com] has joined #wesnoth-dev
20140403 08:19:21-!- DHost [~Pcy@vps.plok.fr] has joined #wesnoth-dev
20140403 08:22:52-!- DHost [~Pcy@vps.plok.fr] has quit [Client Quit]
20140403 08:27:30-!- cib0 [~cib@132.231.178.145] has quit [Ping timeout: 255 seconds]
20140403 08:34:57-!- DHost [~Pcy@vps.plok.fr] has joined #wesnoth-dev
20140403 08:35:56-!- DHost [~Pcy@vps.plok.fr] has quit [Client Quit]
20140403 08:39:45-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginmedia.com] has quit [Remote host closed the connection]
20140403 08:48:28-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140403 09:05:08-!- DHost [~Pcy@vps.plok.fr] has joined #wesnoth-dev
20140403 09:05:47-!- DHost [~Pcy@vps.plok.fr] has quit [Client Quit]
20140403 09:06:02-!- DHost [~Pcy@vps.plok.fr] has joined #wesnoth-dev
20140403 09:29:40-!- cib0 [~cib@132.231.178.68] has joined #wesnoth-dev
20140403 09:48:36-!- knotwork_ [~markm@unaffiliated/knotwork] has quit [Read error: Connection reset by peer]
20140403 09:49:05-!- knotwork_ [~markm@142.68.84.150] has joined #wesnoth-dev
20140403 09:49:05-!- knotwork_ [~markm@142.68.84.150] has quit [Changing host]
20140403 09:49:05-!- knotwork_ [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20140403 09:51:05-!- mjs-de [~mjs-de@f049100161.adsl.alicedsl.de] has joined #wesnoth-dev
20140403 09:56:27-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has joined #wesnoth-dev
20140403 09:59:18-!- cib0 [~cib@132.231.178.68] has quit [Ping timeout: 240 seconds]
20140403 10:10:01-!- RiftWalker [~nathan@129.59.115.25] has quit [Ping timeout: 240 seconds]
20140403 10:36:53-!- kex_ [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 10:43:27-!- irker431 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140403 10:50:35-!- RiftWalker [~nathan@129.59.115.25] has joined #wesnoth-dev
20140403 11:08:58-!- RiftWalker [~nathan@129.59.115.25] has quit [Ping timeout: 240 seconds]
20140403 11:21:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140403 11:27:08-!- Octalot [~noct@27.74.208.46.dyn.plus.net] has quit [Ping timeout: 240 seconds]
20140403 11:31:36-!- cib0 [~cib@132.231.178.93] has joined #wesnoth-dev
20140403 11:36:33-!- RiftWalker [~nathan@129.59.115.25] has joined #wesnoth-dev
20140403 11:48:08-!- RiftWalker [~nathan@129.59.115.25] has quit [Ping timeout: 268 seconds]
20140403 11:52:22-!- Aishiko [~Aishiko@cpe-065-191-176-226.nc.res.rr.com] has quit [Ping timeout: 246 seconds]
20140403 12:01:17-!- Ivanovic [~ivanovic@x2f47313.dyn.telefonica.de] has quit [Changing host]
20140403 12:01:17-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140403 12:01:42-!- cib0 [~cib@132.231.178.93] has quit [Ping timeout: 255 seconds]
20140403 12:03:04< Ivanovic> iceiceice: i feel that having a stringchange now for this does not make sense
20140403 12:03:26-!- kex_ [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140403 12:04:03-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 12:04:41-!- spoffy [~spoffy@host-80-47-182-18.as13285.net] has joined #wesnoth-dev
20140403 12:08:14-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 240 seconds]
20140403 12:09:59-!- irker016 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140403 12:09:59< irker016> wesnoth: Boldizsár Lipka wesnoth:master 81f477f422a8 / src/sdl/texture.cpp: Remove a local variable shadowing a data member. http://git.io/8KaLzQ
20140403 12:10:01< irker016> wesnoth: Boldizsár Lipka wesnoth:master 9a889057cf81 / src/sdl/ (texture.cpp texture.hpp): Use surface instead of SDL_Surface* for storing pixel data. http://git.io/doEB2g
20140403 12:10:56-!- {V} [~V@72-69-ftth.on.nl] has quit [Ping timeout: 265 seconds]
20140403 12:10:58-!- ujdf [~V@72-69-ftth.on.nl] has joined #wesnoth-dev
20140403 12:11:22-!- Aishiko [~Aishiko@cpe-065-191-176-226.nc.res.rr.com] has joined #wesnoth-dev
20140403 12:11:39-!- ujdf is now known as {V}
20140403 12:14:22-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 12:37:37-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 240 seconds]
20140403 12:44:13-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 12:47:23-!- Octalot [~noct@27.74.208.46.dyn.plus.net] has joined #wesnoth-dev
20140403 12:59:45-!- spoffy [~spoffy@host-80-47-182-18.as13285.net] has quit [Ping timeout: 255 seconds]
20140403 13:03:12-!- spoffy [~spoffy@host-80-47-182-18.as13285.net] has joined #wesnoth-dev
20140403 13:05:46-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140403 13:06:17-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Read error: Connection reset by peer]
20140403 13:10:43-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 13:27:12-!- wesbot changed the topic of #wesnoth-dev to: string+feature freeze active on 1.12 | 236 bugs, 352 feature requests, 28 patches | Logs: http://irclogs.wesnoth.org | Alternate logs: http://wesnoth.debian.net | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20140403 13:30:32-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140403 13:40:38-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 240 seconds]
20140403 13:42:02-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 13:49:14-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 240 seconds]
20140403 13:49:38-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 13:49:42-!- noy [~Noy@S01067cb21b205894.vs.shawcable.net] has joined #wesnoth-dev
20140403 13:49:48-!- noy [~Noy@S01067cb21b205894.vs.shawcable.net] has quit [Changing host]
20140403 13:49:48-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 13:55:25-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140403 13:55:59-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 252 seconds]
20140403 13:59:36-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 255 seconds]
20140403 14:06:07-!- Ivanovic [~ivanovic@x2f50fa7.dyn.telefonica.de] has joined #wesnoth-dev
20140403 14:07:29-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20140403 14:13:48-!- Ivanovic [~ivanovic@x2f50fa7.dyn.telefonica.de] has quit [Quit: Caught sigterm, terminating...]
20140403 14:14:17-!- Ivanovic [~ivanovic@x2f50fa7.dyn.telefonica.de] has joined #wesnoth-dev
20140403 14:15:10-!- Ivanovic [~ivanovic@x2f50fa7.dyn.telefonica.de] has quit [Changing host]
20140403 14:15:10-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140403 14:17:56-!- DHost [~Pcy@vps.plok.fr] has quit [Quit: leaving]
20140403 14:23:36-!- DHost [~Pcy@vps.plok.fr] has joined #wesnoth-dev
20140403 14:24:51-!- DHost [~Pcy@vps.plok.fr] has quit [Client Quit]
20140403 14:25:35-!- DHost [~Pcy@vps.plok.fr] has joined #wesnoth-dev
20140403 14:27:19-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140403 14:42:44-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 14:47:48-!- sachith500 [~kvirc@112.134.117.60] has joined #wesnoth-dev
20140403 14:48:38-!- spoffy [~spoffy@host-80-47-182-18.as13285.net] has quit [Ping timeout: 240 seconds]
20140403 14:55:04-!- Samual_ [~dioteckte@xonotic/core-team/Samual] has joined #wesnoth-dev
20140403 14:56:25-!- Samual [~dioteckte@xonotic/core-team/Samual] has quit [Ping timeout: 240 seconds]
20140403 14:58:37< sachith500> Hey AI0867 when you said "If the number of possible outcomes is large (large number of attacks, slow, swarm)"
20140403 14:58:43< sachith500> I get what you mean by swarm
20140403 14:58:51< sachith500> but I don't get how slow affects it
20140403 14:58:58< sachith500> am I missing something?
20140403 15:01:59< sachith500> Does the calculation check for the possibility of slow on each hit and generate the possibilities using those?
20140403 15:02:33< sachith500> taking into account the reduced damage
20140403 15:03:31< sachith500> hmm I shud check that in game :D
20140403 15:05:23< sachith500> ahh
20140403 15:05:25< sachith500> now I see
20140403 15:10:03-!- irker016 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140403 15:19:08-!- sachith500 [~kvirc@112.134.117.60] has quit [Ping timeout: 240 seconds]
20140403 15:25:54-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has joined #wesnoth-dev
20140403 15:26:22-!- spoffy [~spoffy@host-80-47-182-18.as13285.net] has joined #wesnoth-dev
20140403 15:27:53-!- gfgtdf [~chatzilla@f054059140.adsl.alicedsl.de] has joined #wesnoth-dev
20140403 15:28:18< gfgtdf> wesbot: seen iceiceice 
20140403 15:28:18< wesbot> gfgtdf: The person with the nick iceiceice last spoke 7h 49m ago.  7h 47m ago they left with the message: Quit: Leaving
20140403 15:31:21< gfgtdf> iceiceice: can you sel me more abotu skip replays ? is that what the button "Quick replays" does?
20140403 15:31:39< gfgtdf> s/sel/tell
20140403 15:32:15< vultraz> IIRC Quick Replays just skips unit animations
20140403 15:32:56< gfgtdf> 	vultraz: and how do i enabvle skip replays ?
20140403 15:32:59< gfgtdf> enabler
20140403 15:33:26< gfgtdf> enable
20140403 15:34:39< vultraz> I don't know
20140403 15:37:24< gfgtdf> iceiceice: ok i think the problem is after da4cdef146bf5a1b8026f12d6b1caa6c1cd20602 in turn_info::handle_turn we set replay_.set_skip(skip_replay); which just has not effect.
20140403 15:38:44< gfgtdf> iceiceice: i wait for you to be online
20140403 15:38:58< Soliton> gfgtdf: how does the deterministic mode interact with mp games? the attack randomness is still generated by the server, right?
20140403 15:42:14< Soliton> gfgtdf: what does side_invalid=true cause on the client side?
20140403 15:42:18-!- exciton_ [chuck-the-@89.109.217.30] has joined #wesnoth-dev
20140403 15:42:38< gfgtdf> Soliton: no it isn't, attack and other things use the same rng, in https://github.com/wesnoth/wesnoth/blob/master/src/synced_context.cpp#L161  there is an option to set it in a way that the normal(= server sided seed) is only used during attack events, which is not used. I dont know wether i want to allow the deterministic mode in mp, the only reason for that would be a little lower network...
20140403 15:42:39< gfgtdf> ...traffic.
20140403 15:42:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140403 15:43:11< gfgtdf> Soliton: side_invalid=true gives OOs error: https://github.com/wesnoth/wesnoth/blob/master/src/synced_context.cpp#L279
20140403 15:44:57< gfgtdf> soliton: thats the code for random seeds. the code for normal mp sync is here: https://github.com/wesnoth/wesnoth/blob/master/src/replay.cpp#L1019, i think they are much identiavl and should maybe be placed in the same file idk
20140403 15:45:38-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 240 seconds]
20140403 15:47:18< gfgtdf> Soliton: we coudl proceed normaly without OOS when side_invalud is true, but that would give teh user the choice to CHOOSE their own random seeds during attacks.
20140403 15:47:30< gfgtdf> Soliton: which woudl be very bad
20140403 15:48:09< Soliton> which is why i'm wondering why such WML even reaches any client.
20140403 15:49:56< gfgtdf> Soliton: you mean for seed generation for for mp_sync liek advancements ?
20140403 15:50:00< gfgtdf> or forf both
20140403 15:50:02< gfgtdf> for*
20140403 15:51:29< Soliton> no idea what you're saying. i'm talking about WML/commands that are marked as invalid.
20140403 15:53:19< gfgtdf> Soliton: i just thought it's better to know about the error than silently ignoring it especialy since it would normaly be an error in the game if that occured(asuming noone changes the client).
20140403 15:54:47< Soliton> it should certainly not be ignored. there should be a server message announcing the cheat attempt.
20140403 15:56:32< Soliton> as it is now we're hoping the clueless user doesn't just click the dialog away and understands what it is saying. on the server side on the other hand we have no indication whatsoever that something went wrong.
20140403 15:57:30< Soliton> so unless a cheat attempt is done to some developer or some clueful user that reports it we will have no idea.
20140403 15:58:07< gfgtdf> Soliton: but if that happens it could also be a bug ni teh game for some unknown reason
20140403 15:58:38< Soliton> i'd want to know about that, too!
20140403 15:58:42-!- exciton_ [chuck-the-@89.109.217.30] has quit [Read error: Connection reset by peer]
20140403 15:58:56-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:00:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140403 16:00:28< gfgtdf> Soliton: but i thought thats exaclty what the OOS message is for ? Showing a bug /whatever without knowing wherer is it due to a cheat or to a bug.
20140403 16:03:55-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:04:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140403 16:07:10< Soliton> sure, and if you think it's useful in this case (i can't see how it can possibly not be a cheat) the OOS message is fine. of course a) that does not answer why the offending WML needs to reach the client b) my point is that there is no indication on the server side, the perfect side for us to find such issues instead of hoping that someone notices and reports the OOS.
20140403 16:08:55-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:11:10< gfgtdf> Soliton: we have the server sided generated replays where this informations should be found too. idk wether and how other server sided logs exist.
20140403 16:13:29-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140403 16:13:38-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 240 seconds]
20140403 16:13:41< Soliton> they exist like in every other piece of wesnoth code...
20140403 16:13:56-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:16:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140403 16:18:55-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:20:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140403 16:20:18< Soliton> gfgtdf: to be absolutely clear you're really saying that when in deterministic mode the server side RNG is NOT used for attacks?
20140403 16:21:40< gfgtdf> Soliton: yes, there is some code left on the server, but thats only to make older clients work with the new server (note that not possbile that older clients and newer play together).
20140403 16:21:45-!- cib0 [~cib@p5DD215E8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140403 16:23:56-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:23:57< Soliton> gfgtdf: and how did you figure that that was a good feature to implement? it can't be from the forum discussion where several people told you that it's a really bad idea.
20140403 16:24:17< gfgtdf> 	Soliton: whcih feature ?
20140403 16:25:04< Soliton> the deterministic mode.
20140403 16:26:03< gfgtdf> i dint implement the deterministic mode for Mp yet, i wanted to do some  testings to check wether its worth it, and  currently tending to say it's not, still i think its a useful feature for SP.
20140403 16:27:26< gfgtdf> Soliton: the only reson to use it in mp is saving some banwith by not asking the server for a new seed.
20140403 16:27:39< gfgtdf> and my testign showed that that impace it quiet small
20140403 16:27:43< gfgtdf> impact*
20140403 16:28:08-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 240 seconds]
20140403 16:28:56-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:30:42< gfgtdf> Soliton: ofc it's currently possible to enable it by client  modifying for mp, but i wanted to make a check for that as soon as i decied wether i want to make it possible in mp.
20140403 16:33:38-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 240 seconds]
20140403 16:33:55-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:34:17-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140403 16:35:18< shadowm> iceiceice: Why could you test it?
20140403 16:35:21< shadowm> *couldn't
20140403 16:35:32< iceiceice> well skip replays is now broken on master
20140403 16:35:36< iceiceice> thats the only part i couldnt test
20140403 16:36:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140403 16:36:02< iceiceice> i.e. just verifying that selecting that option makes that happen... i'm pretty sure that works anyways though
20140403 16:36:14< iceiceice> i try to be good about testing even the stupid things though
20140403 16:36:41< gfgtdf> iceiceice:iceiceice: did you see my message above ?
20140403 16:37:26< iceiceice> yes
20140403 16:37:58-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 268 seconds]
20140403 16:38:02< iceiceice> gfgtdf: yes so skip replays is a feature to skip animations of moves and attacks to make joining a game as an observer go faster
20140403 16:38:08< iceiceice> the point is you check skip replays in the lobby
20140403 16:38:23< iceiceice> and then when you observe, all animations will be skipped until you reach the current turn
20140403 16:38:28< gfgtdf> iceiceice: do i can test it with the quik_replays button on mp screen
20140403 16:38:30< iceiceice> something in your pr broke the feature, i'm not sure what
20140403 16:38:32< iceiceice> y
20140403 16:38:56-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140403 16:41:01< shadowm> `git bisect` was created to help in these cases. ;)
20140403 16:41:50< shadowm> (Yes, you will need to read some documentation for that, but I find its manpage to be very well-written including simple and relevant examples.)
20140403 16:42:28< gfgtdf> shadowm: you mean me or iceiceice ?
20140403 16:42:39< iceiceice> y i am not sure what the ettiquette is but i think if i have narrowed it down to a particular pull request with thousands of lines changed by one person i've done my job
20140403 16:42:39< shadowm> Whoever wants to find the culprit.
20140403 16:43:16< shadowm> iceiceice: I meant the specifc commit, not series of such.
20140403 16:43:41< iceiceice> yeah so i guess gfgtdf probably has a good idea which one it might be
20140403 16:43:42< shadowm> Finding the specific commit tends to be really helpful IME because it's far easier to tell what's wrong with a single diff.
20140403 16:44:04< vultraz> IME?
20140403 16:44:24< shadowm> Input Method Editor.
20140403 16:44:32< gfgtdf> iceiceice: i have a possible fix but msvc just decided to recpmpile a lot of files that werent changed, so it could take serveral minutes to test it
20140403 16:44:37< iceiceice> ok
20140403 16:44:51< iceiceice> gfgtdf: i'm trying to figure out how to fix the merge conflict i get now with replay.cpp
20140403 16:44:54< shadowm> (Take 'IMO' and find a suitable word starting with 'E' to replace 'Opinion'.)
20140403 16:44:56< iceiceice> it looks like replay.cpp changed alot...
20140403 16:45:13< iceiceice> there was this function "do_replay_handle"
20140403 16:45:15< shadowm> (Also remember what I said the other day about context in linguistics.)
20140403 16:45:21< gfgtdf> iceiceice: yes but i tihnk aour change was easy, and the function do_replay handle still exists
20140403 16:45:24< iceiceice> that used to do things like "if cfg.child("recruit")"
20140403 16:45:31< iceiceice> "if cfg.child("recall")"
20140403 16:45:47< gfgtdf> search for cfg.child("speak
20140403 16:45:49< iceiceice> has the character of the function changed or just those things are handled elsewhere now
20140403 16:47:54< gfgtdf> iceiceice: no all major actions that can be invoked by teh user were moved to synced_commands.cpp to b calles in the line run_in_sycned_context
20140403 16:48:06< iceiceice> ok
20140403 16:48:29< gfgtdf> iceiceice: if your tag invoked an action that is synced and can call random or mp_sync yoou shoudl use run_in_synced_context
20140403 16:48:38< iceiceice> its not
20140403 16:49:01< gfgtdf> iceiceice: like update_shroud, attack or recall
20140403 16:56:04-!- Gallaecio [~quassel@84.120.115.132.dyn.user.ono.com] has joined #wesnoth-dev
20140403 17:13:39-!- neXyon [~neXyon@85-127-239-146.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20140403 17:24:20-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140403 17:32:49-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has quit [Quit: leaving]
20140403 17:40:15-!- Dugi [93fbd156@gateway/web/freenode/ip.147.251.209.86] has joined #wesnoth-dev
20140403 17:43:01-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140403 17:43:16-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Client Quit]
20140403 17:45:55-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20140403 17:48:36< Soliton> gfgtdf: so, currently it is possible for the host(?) to enable deterministic mode in MP, right? and thus be the one to determine the randomness for all clients?
20140403 17:49:20< gfgtdf> Soliton: yes.
20140403 17:49:49< Soliton> gfgtdf: and you're thinking about preventing that somehow in the future?
20140403 17:50:24< gfgtdf> Soliton: yes.
20140403 17:51:09< gfgtdf> Soliton: or at least  giving a warning in chat.
20140403 17:51:34< Soliton> gfgtdf: from the server side?
20140403 17:56:05< gfgtdf> Soliton: no tihnk from client side
20140403 18:00:00-!- iceiceice [~chris@207-237-132-90.ny.subnet.cable.rcn.com] has joined #wesnoth-dev
20140403 18:02:14< iceiceice> gfgtdf: wouldn't that create the possibility to use it to cheat very easily/
20140403 18:02:17< Soliton> gfgtdf: that's what i feared. of course that is quite pointless.
20140403 18:02:43< Soliton> you're expecting the cheating client to announce itself...
20140403 18:03:19< Soliton> it worries me a little that such ideas even come up. :-(
20140403 18:05:33-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 18:05:37< gfgtdf> Soliton: i never said i expect teh chaeting side to announce itself
20140403 18:06:36< gfgtdf> Soliton: all sides know wether the game rund in deterministic mode or, if just one side rund in deterministic mode it will casue OOS just like any other chat.
20140403 18:08:41< gfgtdf> s/ro/or not
20140403 18:08:42< gfgtdf> or
20140403 18:12:49-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20140403 18:18:22-!- neXyon [~neXyon@85-127-239-146.dynamic.xdsl-line.inode.at] has quit [Quit: bye]
20140403 18:19:20-!- neXyon [~neXyon@85-127-239-146.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20140403 18:35:10< Dugi> Guys, do you give also advice about C++ codes that don't belong to wesnoth? Because I've run into a problem that looks completely irrational.
20140403 18:36:08-!- iceiceice [~chris@207-237-132-90.ny.subnet.cable.rcn.com] has quit [Quit: Leaving]
20140403 18:36:09< shadowm_desktop> You can ask general questions if you want, the "don't ask to ask" rule applies to those too.
20140403 18:37:01< shadowm_desktop> Also, in this context code is an uncountable noun.
20140403 18:37:03< Dugi> Okay, I have a global variable, with quite a large dynamically allocated structure.
20140403 18:37:18< Soliton> gfgtdf: ah, i see. that makes more sense then.
20140403 18:37:24< shadowm_desktop> ("ASCII codes" is valid, but not "source codes".)
20140403 18:37:57< Dugi> It calls a function from a shared object, the function is quite complex and I don't know much of its exact implementation.
20140403 18:38:09< Dugi> Then the global variable suddely becomes blank.
20140403 18:38:28< Soliton> gfgtdf: i feared it was similar to the suggestions about droiding sides... ;-)
20140403 18:38:52< Dugi> It happens only if the external function is passed some arguments, otherwise it doesn't do the problem. But the global variable isn't passed it it.
20140403 18:39:31< Soliton> Dugi: show code.
20140403 18:39:32< Dugi> I can't figure out what is going on, I need any ideas about what might actually happen in there, how is it even possble.
20140403 18:40:02-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140403 18:40:17< Soliton> a global variable is... global so why is it surprising that it is changed at any moment?
20140403 18:41:25< Dugi> Soliton: Because the function I call isn't passed any information about it and it is a part of a shared object, not my program.
20140403 18:41:58-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 240 seconds]
20140403 18:42:41-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 18:43:12< shadowm> Also one trap to watch for is that some legacy C runtime library functions conforming to older standards use their own static buffers to store results (e.g. ctime()), so those are overwritten by subsequent calls.
20140403 18:43:43< shadowm> If your global variable is actually a pointer to one such shared buffer, of course it may change behind your back all the time.
20140403 18:44:37< shadowm> This can be extended to any not-quite-very-well-designed library.
20140403 18:44:57< Dugi> This is the code part when it happens: http://pastebin.com/NZHrUMHh It prints an address in the first line, then it prints a zero in the second line. The function on line 2 wasn't compiled with my program and isn't passed anything related to the global variable.
20140403 18:46:05< Dugi> It isn't an old code, I compiled it a few months ago. It uses some other libraries, but they shouldn't be older than a few years for sure.
20140403 18:46:19< shadowm> You'll need to look into the semantics of the API you are using in both cases.
20140403 18:46:32< Soliton> 3 lines! that's quite a generous paste.
20140403 18:46:43< shadowm> And also make sure you aren't using pointers to freed memory that may have been overwritten.
20140403 18:46:51< Dugi> Soliton: Other code is quite unrelated.
20140403 18:47:09< Soliton> well, you've got it all figured out then.
20140403 18:47:14< Soliton> good luck.
20140403 18:48:05< Dugi> shadowm: What do you mean?
20140403 18:56:43< shadowm> Dugi: Here's a thought experiment: { T* foo = new T(); delete foo; U* bar = new U(); foo->method(); } What happens next?
20140403 18:58:26-!- RiftWalker [~nathan@129.59.115.25] has joined #wesnoth-dev
20140403 18:58:30-!- vorobeez [558e940c@gateway/web/freenode/ip.85.142.148.12] has joined #wesnoth-dev
20140403 19:00:35< vorobeez> Hello guys, i want to upload some images for my proposal in wiki, but in sidebar i don't see "Upload file" link. What's wrong?
20140403 19:01:43-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140403 19:02:14< Dugi> shadowm: Ah, that. I haven't done that, I am quite sure of it. I haven't deleted anything so far, I am just in the loading part of the code. The pointer to the beginning of the data structure even exists, just all pointers inside that data structure became blank (but they weren't freed, I can access them without a segfault).
20140403 19:03:37< iceiceice> Dugi: if i find myself in a situation like you are describing where nonsense appears to be happening, what i would suggest is to start removing bits of your program again and again, as long as you can until you get a minimal example
20140403 19:04:18< iceiceice> usually you find that removing some specific part causes the problem to go away and then you understand what was happening
20140403 19:04:48< iceiceice> if you actually get down to like 10-15 lines and still have nonsense, then i guess you would review your understanding of the language / possibly post on stack overflow
20140403 19:05:24< iceiceice> or here
20140403 19:06:26< Dugi> iceiceice: I can't remove most of the code, but I might try to recreate the contents of the global variable locally, somewhere outside loops. Maybe it will help me somehow.
20140403 19:07:57-!- irker395 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140403 19:07:57< irker395> wesnoth: gfgtdf wesnoth:master c181214cb676 / src/playturn.cpp: fix skip_replay part1 http://git.io/AuVq9Q
20140403 19:10:20< Dugi> Soliton: Maybe I misunderstood your reply, but I think that you considered me arrogant. The reason why I didn't post more is that it doesn't happen if that function doesn't call other functions that load three configuration files that seem to work otherwise and the actual meaning of the things in the files is alien to me.
20140403 19:10:38-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 240 seconds]
20140403 19:11:22< iceiceice> Dugi: its just that when you find yourself in a contradiction, usually thats the point where you have to start questioning your assumptions, like "none of this other code is relevant"
20140403 19:11:31< irker395> wesnoth: gfgtdf wesnoth:master c0ea446999f7 / src/playmp_controller.cpp: fix skip_replay part2 http://git.io/PRG4zw
20140403 19:11:54-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 19:11:57< gfgtdf> iceiceice: i comitted some things to fix skip_replay
20140403 19:12:20< iceiceice> did you test it also?
20140403 19:12:22-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20140403 19:12:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140403 19:13:17< gfgtdf> iceiceice	: partly.
20140403 19:13:49-!- vorobeez [558e940c@gateway/web/freenode/ip.85.142.148.12] has quit [Quit: Page closed]
20140403 19:15:40< iceiceice> care to elaborate? i don't have any idea what the issue was so it would be helpful
20140403 19:17:13< Soliton> Dugi: more ignorant. :-P  as iceiceice said, the issue is that you do not know what's wrong so making shortcuts in describing your problem is not helping.
20140403 19:18:01< Soliton> Dugi: cut the problem down to as small a testcase as you can. that helps you understand the issue and makes it easier to present to others.
20140403 19:18:25< gfgtdf> 	iceiceice: before da4cdef146bf5a1b8026f12d6b1caa6c1cd20602 we called replay_.set_skip(skip_replay); after da4cdef146bf5a1b8026f12d6b1caa6c1cd20602 this does not have any effect because we we dont call do_replay(team_num_, &replay_) but do_replay(team_num_) which has the same effect as do_replay(team_num_, &recorder) so in teh fix i called recorder.set_skip(skip_replay_);
20140403 19:18:44< gfgtdf> recorder.set_skip(skip_replay);
20140403 19:20:39< gfgtdf> ^in the fix part1, part 2 does simlar
20140403 19:21:18-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140403 19:21:28< iceiceice> ok thx
20140403 19:21:31< Soliton> Dugi: also note that just because some memory access did not cause a segfault that does not mean everything is fine. it might merely mean you got "lucky". that's some big misconception about undefined behaviour. invoking undefined behaviour (f.e. by accessing unintialised/freed memory) means you can not reason based on anything that happens later. everything might go fine or maybe your disk gets formatted or whatever else...
20140403 19:23:48< Dugi> I've learned that it doesn't happen if I define the global variable in the same file as I use the problematic function.
20140403 19:26:21< Soliton> might be some memory corruption that changes based on the memory layout of your program.
20140403 19:26:51< Soliton> what's farily certain is that the issue is not visible in those 3 lines you pasted. ;-)
20140403 19:26:55-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 19:27:00< gfgtdf> iceiceice: did that fix it for you too ?
20140403 19:27:44< Dugi> With memory corruption, I'd expect a random occurrence, but this happens perfectly reliably.
20140403 19:29:58-!- RiftWalker [~nathan@129.59.115.25] has quit [Ping timeout: 240 seconds]
20140403 19:30:18< Dugi> I have fixed it, but I have no idea why did that fix it.
20140403 19:31:51< iceiceice> gfgtdf: i haven't tested yet
20140403 19:31:53< Dugi> The data isn't blanked if I define a parser object in the function. Any idea how can an unused variable fix an issue?
20140403 19:32:25< iceiceice> Dugi: i dont know, if you want to learn i would suggest to try to make a minimal model of what is happening
20140403 19:37:34-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 240 seconds]
20140403 19:39:08-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 240 seconds]
20140403 19:40:06< Dugi> iceiceice: I can't make a minimal model, if I try to simplify the files that function is reading, it runs without issues. These files are some weird programs in an interpreted language I don't understand at the moment, and understanding their compiler is even harder. I think I'll just let it be, then.
20140403 19:45:57< iceiceice> sorry Dugi, sounds like a bit of a nightmare :/
20140403 19:46:05-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 19:48:12-!- Kexoth [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140403 19:48:53-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 19:50:40< Dugi> iceiceice: I wouldn't be using that if it wasn't extremely useful otherwise (and usable as a black box).
20140403 19:51:48-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 19:53:14-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 240 seconds]
20140403 19:56:15< Soliton> Dugi: you're again expecting too much. why does the memory corruption need to be different every program run? why can't the memory layout just be the same each run unless you change the code?
20140403 19:57:16< Soliton> the way you describe your problem it very much sounds like a memory corruption.
20140403 19:57:42< Soliton> which of course is not a particularly useful diagnosis since that can still mean pretty much anything.
20140403 20:00:02-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140403 20:00:16-!- exciton [chuck-the-@95.72.130.198] has joined #wesnoth-dev
20140403 20:02:58< shadowm> Dugi: You think you haven't done that, but that's why I said that you should inspect the semantics of the API you are using.
20140403 20:03:37< shadowm> Qt is an example of a framework where the concept of object ownership permeates everything and may occasionally result in counter-intuitive behavior.
20140403 20:03:55< shadowm> Dugi: You didn't answer my question, though.
20140403 20:05:22< shadowm> The evidence you have doesn't really help me rule out the aforementioned possibility, and I still consider that thought exercise to be very worthwhile if you take C++ programming seriously.
20140403 20:05:38< shadowm> (Same with C programming.)
20140403 20:06:47< shadowm> Particularly so because while the proposed experiment makes the design issue evident at first sight (and also promotes using operators new and delete which aren't particularly popular in modern C++), there are more roundabout ways to land in the same puddle of mud.
20140403 20:07:00< shadowm> THat has been the source of multiple bugs in Wesnoth, in fact.
20140403 20:08:26< shadowm> The objective of the experiment is to get you familiarized with this wonderful thing called "undefined behavior". A segmentation fault or bus error are generally the best possible outcome in such a situation, but they might not happen at the expected site, or at all.
20140403 20:11:14-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 240 seconds]
20140403 20:11:43-!- markus_ [~mjs-de@g227061233.adsl.alicedsl.de] has joined #wesnoth-dev
20140403 20:15:13-!- mjs-de [~mjs-de@f049100161.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20140403 20:15:56< shadowm> But it feels like you don't want to play along, so you're missing out on the excitingly non-deterministic details.
20140403 20:19:41-!- cib0 [~cib@p5DD215E8.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20140403 20:23:09-!- esr [~esr@wesnoth/developer/esr] has quit [Quit: WeeChat 0.4.1]
20140403 20:23:38-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140403 20:28:23-!- markus_ is now known as mjs-de
20140403 20:33:33< happygrue> But if you do introduce such bugs, you can have someone else undo them with a WesBugGold™ account, right?
20140403 20:33:39< Dugi> shadowm: Sorry I was away for a while. Back to your question: I think that if you call foo, there is nothing allocated, but the data might still be there (but it might be overwritten by bar). The function will be called with the this pointer showing to the unallocated data, which will cause problems, probably a segfault unless the program gets the memory back because of the allocation of bar.
20140403 20:35:38< Dugi> shadowm: I was thinking about the possibility that something took the space and blanked it (debug builds usually do that on delete), but I could not find a possibility how could be delete called upon it.
20140403 20:36:49< shadowm> The effects of the `delete foo;` statement beyond invoking foo's destructor are quite implementation and OS-specific.
20140403 20:38:07< Dugi> shadowm: Does it at least always set the pointer that it's called on to nullptr?
20140403 20:40:01-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140403 20:40:23< shadowm> One implementation might decide to make the memory pointed to by foo immediately available for a new allocation. In such case, it might happen that bar == foo.
20140403 20:41:11< shadowm> Another implementation might mark the memory pointed to by foo as not available for a new allocation.
20140403 20:41:41< Dugi> shadowm: Any idea what does gnu g++:
20140403 20:41:59< shadowm> In that case you might have a case where the memory pointed to by foo is still addressable by the process but zeroed-out, and another where the memory pointed to by foo is still addressable and intact.
20140403 20:42:34< shadowm> _And_ another where the memory pointed to by foo is no longer addressable (the OS might send signal SIGSEGV or SIGBUS to the process).
20140403 20:43:21< shadowm> The memory might be overwritten with a debug pattern instead of being zeroed out. This is occasionally done by memory allocation checkers and debuggers.
20140403 20:43:59< shadowm> The point is that the effect on the memory pointed to by foo is implementation-dependent and you, the C++ programmer, should never rely on one thing or the other happening.
20140403 20:44:32< shadowm> Also, operator delete does not change the pointer.
20140403 20:46:02< shadowm> This makes sense because you pass the *pointer* to operator delete, not a pointer to the pointer, or reference to the pointer.
20140403 20:46:16< Dugi> shadowm: I didn't know that delete doesn't blank the pointer, but I never relied on it.
20140403 20:46:37< shadowm> So it's not the operator delete implementation's business to alter the pointer in any way, only the memory pointed to by the pointer.
20140403 20:47:07< shadowm> Now, let's say that I have an implementation where foo becomes available for a new allocation.
20140403 20:47:34< shadowm> U* bar = new U(); afterwards *may* conceivably reuse the start address of the block pointed to by foo.
20140403 20:47:57< shadowm> Thus foo->method() afterwards results in T::method() being called with this == bar.
20140403 20:48:13< Dugi> shadowm: When trying to find the problem, I have placed the allocator shortly before the problematic function and a std::cerr that is supposed to learn what is inside. I am quite sure that there was no delete between, and the functions called had no access to the variable.
20140403 20:48:20< shadowm> T::method() may use data structures allocated in the block pointed to by bar.
20140403 20:48:48< shadowm> It will use them under the expectations that they have the same layout as those of class T.
20140403 20:49:07< shadowm> Whether that will fail visibly (SIGSEGV or SIGBUS) or not is pretty much a game of chance.
20140403 20:49:36< Dugi> shadowm: But if bar has a proper constructor, its behaviour shouldn't depend on memory garbage.
20140403 20:49:38< shadowm> Perhaps T::method() won't need to dereference data beyond the end of bar.
20140403 20:49:56< shadowm> Dugi: We are not talking of the behavior of bar's methods here.
20140403 20:50:28< shadowm> foo->method() is T::method(), the expectation is that foo's layout is that of type T.
20140403 20:50:42< Dugi> shadowm: Sorry, I confused it. The problem was foo's method used on bar's contents.
20140403 20:51:13< shadowm> If T::method() succeeds, you may experience erratic behavior from the program.
20140403 20:51:47< shadowm> For example, if T::method() checks T::field to call some_function() T::field times.
20140403 20:52:22< shadowm> If the start offset of T::field is not beyond bar's allocation, you might have something unexpected as the value of T::field at that point.
20140403 20:52:48< shadowm> Perhaps instead of a number of iterations, the value is actually now a pointer.
20140403 20:53:34< shadowm> So instead of something that makes sense (say, do 123 iterations), you get *anything* else (0x412A0109 iterations).
20140403 20:54:12< shadowm> Now, place whatever you want between `delete foo;` and the instantiation of bar.
20140403 20:54:20< Dugi> shadowm: That is an interesting case, something that is similar to segmentation error disguises as an endless loop.
20140403 20:54:49< shadowm> Under the same implementation, if you do more memory allocations in  between, you get a different final result by the point you call foo->method().
20140403 20:55:13< shadowm> Perhaps the code running between the destruction and post-destruction method call deterministically does N allocations every time.
20140403 20:55:38< shadowm> Perhaps it randomly does a different number of allocations each time (esp. code that deals with interactive events).
20140403 20:56:07< shadowm> So this is why you cannot rely on use-after-free having a particular effect.
20140403 20:56:16< Dugi> shadowm: That would explain why changing the configuration code the problematic function read caused a change in behaviour elsewhere.
20140403 20:57:00< shadowm> The factors involved are the compiler, the implementation of operators new and delete, the implementation of their implementation, and how the opearting system kernel lays out virtual memory for a given process under different runtime conditions (perhaps even including the time of the day).
20140403 20:57:19< shadowm> And whether you have a debugger attached or not. And whether the compiler has optimized away some operations.
20140403 20:58:02< shadowm> So I can't say whether you are experiencing a case of this or not, but it's important to keep it in mind at all times, especially when debugging misbehavior involving third-part[Dy code.
20140403 20:58:02< Dugi> shadowm: But this problem happened even if I created foo just before calling the function and read it right after it.
20140403 20:59:05< shadowm> And when dealing with multithreaded applications, well, it's complete chaos.
20140403 20:59:07< Dugi> shadowm: But the other symptoms are present, it didn't happen if the object wasn't global or if the configuration files were simpler.
20140403 21:00:14< shadowm> Every tiny change can result in the memory layout changing every time.
20140403 21:00:37< Dugi> shadowm: The API was multithreaded, and possibly some multithreading was used between the parts of code where it was created and where the problem occurred. But it also happened when they were in the same function.
20140403 21:00:54< shadowm> So the point here is that first and foremost you need to understand the API you are using.
20140403 21:01:10< shadowm> You need to understand in detail what its side-effects can be.
20140403 21:01:33< shadowm> For example, in Wesnoth GUI1 code, dialog widgets are instantiated by the client using operator new.
20140403 21:01:45< shadowm> They are thus not bound to be destroyed at the end of the scope.
20140403 21:02:12< shadowm> However, they can be attached to a dialog that takes ownership of their memory. When that dialog is destroyed, their memory is released.
20140403 21:02:18-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140403 21:02:42-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 21:03:41< Dugi> shadowm: The API is really complex, so the possibility that I missed something related to the API is not impossible.
20140403 21:04:33< shadowm> That's why it's important to take the time to understand how to use an API before throwing code at the compiler using it.
20140403 21:07:08-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 240 seconds]
20140403 21:08:48-!- RiftWalker [~nathan@129.59.115.25] has joined #wesnoth-dev
20140403 21:10:51-!- exciton [chuck-the-@95.72.130.198] has quit [Read error: Connection reset by peer]
20140403 21:11:06-!- exciton [chuck-the-@95.72.130.198] has joined #wesnoth-dev
20140403 21:19:42< irker395> wesnoth: Chris Beck wesnoth:master 8e5572a239eb / src/ (replay.cpp server/game.cpp server/server.cpp): make server level_ reflect true start of game position http://git.io/IHvr7w
20140403 21:19:44< irker395> wesnoth: Chris Beck wesnoth:master fb726e0610af / src/ (7 files in 2 dirs): move controller tweaks to server http://git.io/65UO2g
20140403 21:19:46< irker395> wesnoth: Chris Beck wesnoth:master 1c4ba02a3097 / src/ (8 files in 2 dirs): Merge pull request #123 from cbeck88/server_controller_tweaks http://git.io/XqzC5A
20140403 21:20:05-!- Coffee_irc [~david@ppp118-210-45-181.lns20.adl2.internode.on.net] has quit [Quit: Konversation terminated!]
20140403 21:32:46< iceiceice> gfgtdf: are you going to push all that sync stuff to 1.12?
20140403 21:33:02< iceiceice> if you are going to then i shouldn't try to cherrypick the two commits i just pushed to master until you are done
20140403 21:33:08-!- gfgtdf [~chatzilla@f054059140.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20140403 21:33:18< iceiceice> because it will make me resolve merge conflicts and then you will have to resolve them again
20140403 21:33:41< iceiceice> i'll wait until you decide i guess
20140403 21:36:46-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Quit: No Ping reply in 180 seconds.]
20140403 21:37:08-!- happygrue [~happygrue@2601:6:4380:7df:34a7:7167:a1c4:110c] has joined #wesnoth-dev
20140403 21:37:08-!- happygrue [~happygrue@2601:6:4380:7df:34a7:7167:a1c4:110c] has quit [Changing host]
20140403 21:37:08-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140403 21:42:39-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140403 21:53:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds]
20140403 21:57:21-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20140403 22:02:42-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Quit: Vannak idők, mikor menni kell]
20140403 22:07:41-!- Grickit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140403 22:09:12-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Ping timeout: 255 seconds]
20140403 22:10:51-!- Grickit is now known as Gambit
20140403 22:15:03-!- neXyon [~neXyon@85-127-239-146.dynamic.xdsl-line.inode.at] has quit [Quit: bye]
20140403 22:19:47-!- exciton [chuck-the-@95.72.130.198] has quit [Read error: Connection reset by peer]
20140403 22:20:02-!- exciton [chuck-the-@95.72.130.198] has joined #wesnoth-dev
20140403 22:23:15< irker395> wesnoth: Chris Beck wesnoth:master 9f334718af39 / changelog: update changelog http://git.io/FcBC0Q
20140403 22:29:29-!- exciton [chuck-the-@95.72.130.198] has quit [Read error: Connection reset by peer]
20140403 22:29:43-!- exciton [chuck-the-@95.72.130.198] has joined #wesnoth-dev
20140403 22:32:31< iceiceice> gfgtdf: the skip replay works for me now too as far as i can tell
20140403 22:38:38-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Ping timeout: 240 seconds]
20140403 22:41:55-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140403 22:42:38-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has joined #wesnoth-dev
20140403 22:43:55-!- exciton [chuck-the-@95.72.130.198] has quit [Read error: Connection reset by peer]
20140403 22:44:09-!- exciton [chuck-the-@95.72.130.198] has joined #wesnoth-dev
20140403 22:49:01-!- exciton [chuck-the-@95.72.130.198] has quit [Read error: Connection reset by peer]
20140403 22:49:15-!- exciton [chuck-the-@95.72.130.198] has joined #wesnoth-dev
20140403 23:02:49-!- RiftWalker [~nathan@129.59.115.25] has quit [Ping timeout: 240 seconds]
20140403 23:02:52-!- RiftWalk1r [~nathan@129.59.115.25] has joined #wesnoth-dev
20140403 23:09:29-!- gfgtdf [~chatzilla@f054128068.adsl.alicedsl.de] has joined #wesnoth-dev
20140403 23:10:01-!- RiftWalk1r [~nathan@129.59.115.25] has quit [Ping timeout: 240 seconds]
20140403 23:10:58< gfgtdf> iceiceice: ok i marked the bug in gna as fixed.
20140403 23:18:15-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140403 23:20:34-!- mjs-de [~mjs-de@g227061233.adsl.alicedsl.de] has quit [Remote host closed the connection]
20140403 23:22:18-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 240 seconds]
20140403 23:26:12< irker395> wesnoth: gfgtdf wesnoth:master 9d3594620ed7 / data/gui/default/window/campaign_dialog.cfg: added forgotten translatable mark http://git.io/b9h59Q
20140403 23:38:08-!- Dugi [93fbd156@gateway/web/freenode/ip.147.251.209.86] has quit [Ping timeout: 245 seconds]
20140403 23:38:39-!- Samual_ [~dioteckte@xonotic/core-team/Samual] has quit [Ping timeout: 252 seconds]
20140403 23:42:27-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140403 23:55:50-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
--- Log closed Fri Apr 04 00:00:48 2014