--- Log opened Fri Nov 18 00:00:16 2016
20161118 00:10:45-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161118 00:21:37-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20161118 00:22:41-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:6de9:6ba8:d373:278] has joined #wesnoth-dev
20161118 00:22:44-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:6de9:6ba8:d373:278] has quit [Remote host closed the connection]
20161118 00:33:23-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161118 00:51:58-!- gfgtdf_ [~chatzilla@x4e36a1b5.dyn.telefonica.de] has joined #wesnoth-dev
20161118 00:55:03-!- gfgtdf [~chatzilla@x4e36a1b5.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
20161118 00:55:08-!- gfgtdf_ is now known as gfgtdf
20161118 01:00:53-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20161118 01:09:01-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161118 01:31:29-!- irker772 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161118 01:45:28-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161118 01:47:21-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20161118 01:47:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 01:49:40-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 01:56:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20161118 01:56:42-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 01:57:48-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161118 02:03:59-!- travis-ci [~travis-ci@ec2-54-198-6-32.compute-1.amazonaws.com] has joined #wesnoth-dev
20161118 02:04:00< travis-ci> wesnoth/wesnoth#12102 (spirit_po - e9c32ee : Celtic Minstrel): The build passed.
20161118 02:04:00< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/176858097
20161118 02:04:00-!- travis-ci [~travis-ci@ec2-54-198-6-32.compute-1.amazonaws.com] has left #wesnoth-dev []
20161118 02:04:09-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20161118 02:07:04-!- gfgtdf_ [~chatzilla@x4e368bbc.dyn.telefonica.de] has joined #wesnoth-dev
20161118 02:08:58-!- gfgtdf [~chatzilla@x4e36a1b5.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161118 02:08:59-!- gfgtdf_ is now known as gfgtdf
20161118 02:11:17-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 248 seconds]
20161118 02:13:19-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161118 02:16:27-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 02:21:25-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20161118 02:21:55-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 02:25:59-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 02:28:06-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 246 seconds]
20161118 02:33:11-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161118 02:34:26-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 02:40:49-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 49.0.2/20161019084923]]
20161118 02:42:53-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161118 02:43:48-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20161118 02:44:41-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 02:44:59-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 02:46:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 02:46:55-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20161118 02:49:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20161118 02:49:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 02:58:09-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161118 03:02:01-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 03:11:23-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161118 03:13:20-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has joined #wesnoth-dev
20161118 03:13:20-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has quit [Changing host]
20161118 03:13:20-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 03:17:05-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 256 seconds]
20161118 03:17:05-!- noy_ is now known as noy
20161118 03:17:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161118 03:28:18-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161118 03:28:48-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 05:10:55-!- Bonobo [~Bonobo@2001:44b8:254:3200:644c:b58:7d10:9d08] has quit [Quit: Leaving]
20161118 05:28:44-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161118 05:31:26< wedge009> I don't seem to be one of the 8 million, but this may be of interest to the rest of you: https://www.troyhunt.com/8-million-github-profiles-were-leaked-from-geekedins-mongodb-heres-how-to-see-yours/
20161118 05:31:51< wedge009> And yes, he's a trustworthy fellow.
20161118 05:40:51< celticminstrel> Looks like I can't even determine if I'm included, since my email is private.
20161118 05:56:33< pydsigner> It's just emails though
20161118 05:56:43< pydsigner> Public info
20161118 05:57:03< celticminstrel> Not just emails, but yes, just info that was already public.
20161118 05:57:20< pydsigner> Because it was scraped from GitHub
20161118 06:02:14-!- JyrkiVesterinen [~JyrkiVest@87-100-200-153.bb.dnainternet.fi] has joined #wesnoth-dev
20161118 06:03:15-!- Appleman1234_ [~Appleman1@KD106161198040.au-net.ne.jp] has joined #wesnoth-dev
20161118 06:04:40< wedge009> I think it's the potential mis-use of the information that's the concern here.
20161118 06:05:44-!- Appleman1234 [~Appleman1@KD106161204096.au-net.ne.jp] has quit [Disconnected by services]
20161118 06:05:49-!- Appleman1234_ is now known as Appleman1234
20161118 07:10:08-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161118 07:20:06-!- JyrkiVesterinen [~JyrkiVest@87-100-200-153.bb.dnainternet.fi] has quit [Quit: .]
20161118 07:32:51-!- atarocch [~atarocch@109.112.49.33] has joined #wesnoth-dev
20161118 07:54:16-!- atarocch [~atarocch@109.112.49.33] has quit [Ping timeout: 260 seconds]
20161118 08:07:56-!- atarocch [~atarocch@188.73.254.131] has joined #wesnoth-dev
20161118 08:56:56-!- boucman_work [~boucman@129.16.90.92.rev.sfr.net] has joined #wesnoth-dev
20161118 10:12:04-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161118 10:12:20-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161118 10:14:20-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161118 10:16:21-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161118 10:17:08-!- DeFender1031 [~DeFender1@46-116-88-23.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20161118 10:27:03-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161118 10:27:21-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161118 10:27:35-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has joined #wesnoth-dev
20161118 10:28:08-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161118 10:28:31-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161118 10:30:48-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161118 10:32:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20161118 10:32:33-!- wedge010 is now known as wedge009
20161118 10:58:36-!- Appleman1234 [~Appleman1@KD106161198040.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20161118 11:15:50-!- Appleman1234 [~Appleman1@KD106161198040.au-net.ne.jp] has joined #wesnoth-dev
20161118 11:25:55-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161118 11:47:05-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 12:05:50-!- nore [~ncourant@sas.eleves.ens.fr] has quit [Ping timeout: 250 seconds]
20161118 12:10:15-!- nore [~ncourant@sas.eleves.ens.fr] has joined #wesnoth-dev
20161118 12:10:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 12:19:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 258 seconds]
20161118 12:19:25-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 12:27:07-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161118 13:00:36-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161118 13:00:45-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 13:16:49-!- atarocch [~atarocch@188.73.254.131] has quit [Remote host closed the connection]
20161118 13:34:49-!- iwaim [~iwaim@2001:2c0:40e:2002:654e:d284:6c50:56ce] has quit [Ping timeout: 260 seconds]
20161118 13:46:49-!- iwaim [~iwaim@124.146.179.10] has joined #wesnoth-dev
20161118 13:57:21-!- boucman_work [~boucman@129.16.90.92.rev.sfr.net] has quit [Ping timeout: 252 seconds]
20161118 14:09:44-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161118 14:34:04-!- irker869 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161118 14:34:04< irker869> wesnoth: Jyrki Vesterinen wesnoth:master 889e5a8fd64a / / (7 files in 3 dirs): Size lock widget, the C++ part https://github.com/wesnoth/wesnoth/commit/889e5a8fd64ab8c88de52480182eaca18b3f44b2
20161118 14:34:04< irker869> wesnoth: Jyrki Vesterinen wesnoth:master 8f404621160c / data/gui/ (macros/_initial.cfg schema.cfg widget/size_lock_default.cfg): Size lock widget, the WML part https://github.com/wesnoth/wesnoth/commit/8f404621160ca00db8e10e74325af867d8b4f6ec
20161118 14:34:05< irker869> wesnoth: Jyrki Vesterinen wesnoth:master 4ed014625158 / data/gui/window/ (lobby_main.cfg mp_join_game.cfg mp_staging.cfg): Lock sizes of all chat boxes https://github.com/wesnoth/wesnoth/commit/4ed014625158e39749603d6fd4c34f1f55ab1fa3
20161118 14:34:06< irker869> wesnoth: Jyrki Vesterinen wesnoth:master 57b33f390386 / src/gui/core/window_builder.cpp: Attempted fix for WML unit tests failing https://github.com/wesnoth/wesnoth/commit/57b33f390386c745b408e5414c2d31e8aebef499
20161118 14:34:07< irker869> wesnoth: Jyrki Vesterinen wesnoth:master c1f1a61f686d / / (14 files in 8 dirs): Merge pull request #859 from wesnoth/fixed-size-chatbox https://github.com/wesnoth/wesnoth/commit/c1f1a61f686d43ecbfab3b8745eecb3af8fc6307
20161118 14:34:14< vultraz> ermeghard :D
20161118 14:34:16< vultraz> it is here
20161118 14:34:43< JyrkiVesterinen> Indeed it is. :)
20161118 14:38:46< vultraz> will you be tackling the mp tests next?
20161118 14:39:16< JyrkiVesterinen> Yes. I plan to get to it early next week.
20161118 14:40:07< vultraz> also, why is my compiler complaining when passing a function that takes a non-const copy to a function that takes a const reference...
20161118 14:40:31< vultraz> (unrelated to size lock)
20161118 14:41:48< vultraz> ie, it doesn't like a bool(T foo) function being passed as an argument that wants bool(const T& foo)... I'd think it wouldn't matter, but oh well.
20161118 14:41:49< JyrkiVesterinen> C++ requires function signatures to match very closely when you pass function objects around.
20161118 14:42:29< JyrkiVesterinen> Maybe being less strict would be possible, but the language just doesn't work like that right now.
20161118 14:42:45< vultraz> i guess i can use std::bind
20161118 14:43:12< vultraz> but whatever, I'll be lazy and change the function declaration.
20161118 14:43:22< vultraz> i should have made this function take a const reference anyway
20161118 14:43:48< vultraz> (another solution would be using 'auto' but we don't have that yet :| )
20161118 14:45:09< JyrkiVesterinen> Auto parameter? IIRC, C++14 allows auto parameters only in lambdas, not in functions.
20161118 14:46:20< vultraz> really?
20161118 14:47:29< JyrkiVesterinen> https://en.wikipedia.org/wiki/C%2B%2B14#Generic_lambdas
20161118 14:48:43< JyrkiVesterinen> I found this with a quick search: https://www.quora.com/Can-we-use-auto-in-function-parameter-declaration-in-C++
20161118 14:49:11< JyrkiVesterinen> Auto parameters are part of the Concepts proposal. Concepts have been delayed to C++20 at best. :(
20161118 14:49:52< vultraz> aw
20161118 14:50:17< vultraz> blah, this function is not cooperating 
20161118 14:50:19< vultraz> bind it is
20161118 14:51:12< vultraz> btw, should one always take function parameters by copy or by reference?
20161118 14:51:30< vultraz> or, more specifically, is copy safer since reference could cause problems with lambdas?
20161118 14:53:40< JyrkiVesterinen> Copying is safer indeed. A reference can point to an object that has been already destroyed: the same thing can't happen with copies.
20161118 14:54:19< JyrkiVesterinen> General advice is to prefer copying for primitive types (integers, booleans, floats) and const references for complex types (e.g. units).
20161118 14:55:20-!- stikonas_ is now known as stikonas
20161118 14:56:29< JyrkiVesterinen> References cause problems with lambdas in particular because a lambda can outlive its enclosing scope. It is common to specify lambda as a "button clicked callback" or something that will be called long after the enclosing function has returned. Carelessly capturing local variables by reference results in use-after-free bugs.
20161118 14:57:38< JyrkiVesterinen> Regular functions are used that way less often, and the problem is less common with them. It's still possible though, especially with std::bind().
20161118 15:00:02< vultraz> blagh
20161118 15:06:48-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has quit [Quit: Going home]
20161118 15:07:13< loonycyborg> you can capture by value though
20161118 15:07:30< vultraz> that blagh was about something else
20161118 15:08:02< vultraz> i can never figure out how to use bind for an non-same-class or static/anon function >_>
20161118 15:08:05< vultraz> lambda it is!
20161118 15:16:33-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161118 15:20:49< vultraz> ...huh
20161118 15:21:01< vultraz> is the default value of a pointer not a nullptr?
20161118 15:22:01< vultraz> I assumed it was
20161118 15:22:22< vultraz> ie, T* ptr;, ptr == nullptr would be true
20161118 15:22:29< vultraz> but that seems to be... not the case?
20161118 15:24:27< vultraz> confused, I am
20161118 15:25:04< vultraz> I have come code here that's essentially T* ptr. ... stuff... if(!ptr) return; ... stuff ...
20161118 15:25:19< vultraz> if i leave it like that, it seems the second stuff is executed
20161118 15:25:26-!- boucman_work [~boucman@161.21.90.92.rev.sfr.net] has joined #wesnoth-dev
20161118 15:25:28< vultraz> but if i do T* ptr = nullptr;, it's not\
20161118 15:25:30< vultraz> :/
20161118 15:26:53-!- prkc_ [~prkc@46.166.190.224] has joined #wesnoth-dev
20161118 15:28:40-!- prkc_ [~prkc@46.166.190.224] has quit [Client Quit]
20161118 15:29:00< loonycyborg> vultraz: there are no default values in C++
20161118 15:29:16< loonycyborg> at least for simple types like pointers
20161118 15:29:29< vultraz> annoying, this is :/
20161118 15:30:29< loonycyborg> better initialize such stuff when you declare it
20161118 15:30:53< loonycyborg> compilers have warnings about possible uses of such variables when they're uninitialized
20161118 15:31:21< loonycyborg> since it's undefined behavior
20161118 15:31:42< loonycyborg> until it's initialized such variable will contain garbage from stack
20161118 15:31:53< loonycyborg> or something along those lines :P
20161118 15:32:36< loonycyborg> that's part of C heritage
20161118 15:43:07-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161118 15:57:48-!- atarocch [~atarocch@93.68.244.142] has joined #wesnoth-dev
20161118 16:01:37< vultraz> another blagh
20161118 16:03:55 * vultraz is stuck in a logical conundrum
20161118 16:07:44< loonycyborg> To be or not to be?
20161118 16:09:18< vultraz> no, the simplest way to make sure a bool flag is true if foo OR if every case of bar is false on every iteration of a loop.
20161118 16:10:58< vultraz> i can easily make it do one or the other but i can't see a way to do both without a second temp variable 
20161118 16:11:28-!- atarocch [~atarocch@93.68.244.142] has quit [Ping timeout: 244 seconds]
20161118 16:13:17< vultraz> do bitwise ops even have any special effect with bools or have i been wasting the last half hour?
20161118 16:20:18-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161118 16:20:38-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 16:27:36-!- boucman_work [~boucman@161.21.90.92.rev.sfr.net] has quit [Ping timeout: 260 seconds]
20161118 16:34:24-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161118 16:39:53-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 244 seconds]
20161118 16:49:17-!- boucman_work [~boucman@108.202.154.77.rev.sfr.net] has joined #wesnoth-dev
20161118 16:55:21< loonycyborg> hmm bitwise and logical operations are totally different things
20161118 16:55:53< loonycyborg> bitwise applies that op to every bit of both operands
20161118 16:56:34< loonycyborg> while logical operations on bool care only about true vs false value for entire variable
20161118 16:57:19< loonycyborg> bool variable is in fact some kind of integer
20161118 16:57:53< loonycyborg> but logical operation consider zero value of it to be false and non-zero to be true
20161118 16:59:01< loonycyborg> So I'd say doing bitwise directly on boolean is undefined behavior :P
20161118 17:07:17-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161118 17:10:48-!- boucman_work [~boucman@108.202.154.77.rev.sfr.net] has quit [Remote host closed the connection]
20161118 17:10:58< celticminstrel> So I think spirit_po is ready for merge. Any comments, objections, etc?
20161118 17:11:22-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has joined #wesnoth-dev
20161118 17:11:55< celticminstrel> gfgtdf, any objections to merging spirit_po?
20161118 17:12:09 * celticminstrel pokes vultraz too
20161118 17:14:18< celticminstrel> Link: https://github.com/wesnoth/wesnoth/pull/684
20161118 17:15:33< gfgtdf> celticminstrel: looks good to me but i didn't test it.
20161118 17:16:36< gfgtdf> celticminstrel: about "MO files require the gettext tools to create", dopn't you still need the gettext tool to extracet the trnaslatable strings form an source and to put them into a  pot file?
20161118 17:17:03-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 17:17:33-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161118 17:18:24< gfgtdf> zookeeper: did you see http://gna.org/bugs/?25311 ?
20161118 17:19:18< gfgtdf> zookeeper: it remembers me of the LoW bugs (like for example: kalenz suddenly switches to the enemy orcish side and starts recruiting drakes)
20161118 17:21:56< vultraz> celticminstrel: hm?
20161118 17:21:57< vultraz> no
20161118 17:29:32< loonycyborg> celticminstrel: In its current form does it cause any changes for packaging?
20161118 17:31:34< loonycyborg> seems you have still support for .mo files
20161118 17:31:46< loonycyborg> so I guess it should work as before
20161118 17:32:37< vultraz> would it be a problem if it did?
20161118 17:34:10-!- irker869 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161118 17:39:56-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 17:47:25< celticminstrel> loonycyborg: It doesn't cause any changes for packaging in its current form.
20161118 17:47:39< loonycyborg> cool
20161118 17:47:43< celticminstrel> vultraz: I think it'd be less a "problem" and more "something that needs to be announced on the ML".
20161118 17:48:21< celticminstrel> gfgtdf: You don't need the gettext tools to extract the translatable strings from WML, because Wesnoth provides its own tool for that.
20161118 17:48:34< gfgtdf> celticminstrel: for lua too ?
20161118 17:48:47< celticminstrel> (Speaking of which, shouldn't wmlxgettext be included in the package? IIRC it's not included ATM.)
20161118 17:48:57< celticminstrel> gfgtdf: Yes, wmlxgettext works for WML and Lua.
20161118 17:50:27< celticminstrel> Okay, since there are no objections, I'm pushing.
20161118 17:51:06< loonycyborg> wmlxgettext is included only in source package atm
20161118 17:51:13< zookeeper> gfgtdf, no i didn't, sounds like a fun bug.
20161118 17:51:20< celticminstrel> Yeah, that's what I mean.
20161118 17:51:35-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Read error: Connection reset by peer]
20161118 17:51:36-!- irker885 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161118 17:51:36< irker885> wesnoth: Celtic Minstrel wesnoth:master b5b086a3b2e6 / src/ (filesystem_boost.cpp wesnoth.cpp): Normalize data and userdata paths https://github.com/wesnoth/wesnoth/commit/b5b086a3b2e6108afbf0c4789c062015f3c873c7
20161118 17:51:36< irker885> wesnoth: Celtic Minstrel wesnoth:master 379df76dcb08 / src/log.cpp: Fix general logdomain being unavailable from commandline https://github.com/wesnoth/wesnoth/commit/379df76dcb081f8a89176c98a759c5630b622cd6
20161118 17:51:36< irker885> wesnoth: Celtic Minstrel wesnoth:master dc24fa16f7d4 / / (11 files in 6 dirs): Remove option to link libintl instead of Boost.Locale https://github.com/wesnoth/wesnoth/commit/dc24fa16f7d43b0595e8512a9526e5eea68403ec
20161118 17:51:37< irker885> wesnoth: Celtic Minstrel wesnoth:master 4bc0563e73c7 / src/gettext_boost.cpp: This namespace alias is defined, so might as well use it https://github.com/wesnoth/wesnoth/commit/4bc0563e73c7b4edf8a1881743720f66554caf24
20161118 17:51:38< irker885> wesnoth: Celtic Minstrel wesnoth:master 6c32ccb3c300 / src/ (10 files in 2 dirs): Add new translation library https://github.com/wesnoth/wesnoth/commit/6c32ccb3c3006eb10fcddfa189b1650fc7c63289
20161118 17:51:40< irker885> wesnoth: Celtic Minstrel wesnoth:master fffe3d5d7a45 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj src/gettext_boost.cpp: Enable loading of po files in addons https://github.com/wesnoth/wesnoth/commit/fffe3d5d7a4553029e3cd556679d0c1254931cb3
20161118 17:51:42< irker885> wesnoth: Celtic Minstrel wesnoth:master d0700ede4510 / src/gettext_boost.cpp: Silence GCC warnings in spirit_po headers https://github.com/wesnoth/wesnoth/commit/d0700ede451066b7c888513fbb08bb57c72c886d
20161118 17:51:44< irker885> wesnoth: Celtic Minstrel wesnoth:master c3ee41785579 / / (25 files in 7 dirs): Merge pull request #684 from wesnoth/spirit_po https://github.com/wesnoth/wesnoth/commit/c3ee41785579a66ba78309330e463e4690df266a
20161118 17:52:12-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 17:56:10< celticminstrel> Okay, so PRs that should probably be dealt with soon... 874, 861, 847, 804, 785, 616. Maybe 844, not sure of the status on that.
20161118 18:00:49< vultraz> yayyy spirit po!
20161118 18:00:56< vultraz> good work, celmin
20161118 18:04:13< celticminstrel> Also, we need to fix the MP tests.
20161118 18:05:24< celticminstrel> Also, I have way too many stashes.
20161118 18:06:36< vultraz> doesn't saving a new over override the last one?
20161118 18:06:43< celticminstrel> No, it's a stack.
20161118 18:06:51< vultraz> oh deer
20161118 18:06:56< celticminstrel> "git stash list"
20161118 18:06:58< vultraz> p_p
20161118 18:07:17< vultraz> huh
20161118 18:07:20< vultraz> i only have 11?
20161118 18:07:39< celticminstrel> "git stash show -p stash@{x}" if you want to know what they are
20161118 18:07:55< celticminstrel> "git stash drop stash@{x}" to delete it
20161118 18:09:22< vultraz> can you drop them all?
20161118 18:09:29< celticminstrel> I think so.
20161118 18:09:38-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161118 18:09:39< celticminstrel> Not sure of the command, maybe "git stash clear"?
20161118 18:09:52< vultraz> works
20161118 18:09:54< vultraz> ty
20161118 18:10:05< tad_carlucci> PR 847 will want to be sure that it does not use function-sections or gl-sections on debug builds. I proposed those separately and the objection was they disable the abililty to do some debugging, mainly gprof.
20161118 18:10:45< tad_carlucci> The better solution would be to figure out which functions are being dropped by the linker and split them into separate source files.
20161118 18:11:05< celticminstrel> I have 39 stashes, and that's after deleting a couple... >_>
20161118 18:11:19< celticminstrel> I think stash 32 is broken actually...
20161118 18:11:47< tad_carlucci> You can ask for the patch diff and see what it does. Probably a lot of them no longer have any meaning.
20161118 18:12:01< celticminstrel> I can't show or delete it, so it's just stuck there until I feel that I can clear the stashlist.
20161118 18:12:19< celticminstrel> You're probably right that a lot of them no longer have any meaning.
20161118 18:13:17< zookeeper> i have 40 stashes, 30 of them named "stuff"
20161118 18:13:27< celticminstrel> I generally don't name my stashes.
20161118 18:14:08< celticminstrel> Apparently I have a stash fiddling with runpath settings in the XCode project.
20161118 18:15:11< celticminstrel> One stash is just a few TODO comments. >_>
20161118 18:15:48-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161118 18:15:51< celticminstrel> Oh, I have a stash with WFL set-operation functions.
20161118 18:16:06< celticminstrel> ie union, intersection, difference, and symmetric difference
20161118 18:23:46-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161118 18:32:45-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Read error: Connection reset by peer]
20161118 18:33:23-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 18:39:26-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20161118 18:41:11-!- JyrkiVesterinen [~JyrkiVest@87-92-31-135.bb.dnainternet.fi] has joined #wesnoth-dev
20161118 18:46:49-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161118 18:49:22-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161118 18:49:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161118 18:50:28-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Client Quit]
20161118 18:55:45-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161118 19:20:20< vultraz> celticminstrel: http://pastebin.com/ThgNXwPQ could you help me puzzle out why this works
20161118 19:21:05< vultraz> specifically the if(!do_reselect && had_selection) { seems backwards..
20161118 19:21:14< vultraz> but it doesn't work with !had_selection like I expected
20161118 19:21:19< celticminstrel> Okay, what does this do.
20161118 19:21:24< celticminstrel> In particular, what class is it in.
20161118 19:21:40< vultraz> local change to gui2::group
20161118 19:21:50< celticminstrel> Okay, so...
20161118 19:22:17< celticminstrel> I question the motivation behind this, but...
20161118 19:22:35< vultraz> i was trying to make it reselect a button if necessary, which do_reselect seems to handle fine
20161118 19:22:43< vultraz> since line 21 is never reached unless that happens
20161118 19:22:57< vultraz> but that doesn't cover cases where all buttons were disabled (and hence noting selected)
20161118 19:23:14< celticminstrel> Well, mainly what I'm questioning is that this function's interface implies that multiple simultaneous selections are allowed.
20161118 19:23:24< vultraz> eh?
20161118 19:23:29< vultraz> no, that's not the case..
20161118 19:23:31< vultraz> how does it do so?
20161118 19:23:42< celticminstrel> I'm talking about the interface, not the implementation.
20161118 19:24:11< celticminstrel> The name, "set_members_active", combined with the fact that it takes a predicate, implies that it will set active all members for which the predicate returns true.
20161118 19:24:20< celticminstrel> In other words, the interface seems misleading.
20161118 19:24:31< vultraz> eh
20161118 19:24:32< vultraz> hm
20161118 19:24:34< vultraz> well
20161118 19:24:39< vultraz> that's... actually what it does :/
20161118 19:24:51< celticminstrel> Eh?
20161118 19:25:22< vultraz> i mean, it's not.. really supposed to
20161118 19:25:28< vultraz> but i guess it technically would
20161118 19:25:47< vultraz> i decided it might be better to just pass a predicate function instead of setting the state of every member manually
20161118 19:26:04< vultraz> and
20161118 19:26:06< vultraz> wait
20161118 19:26:07< vultraz> ...
20161118 19:26:11< vultraz> wait, this is for *active*
20161118 19:26:17< vultraz> blagh
20161118 19:26:18< vultraz> stop confusing me
20161118 19:26:19< celticminstrel> What've you suddenly realized.
20161118 19:26:36< vultraz> remember, active is different from selected
20161118 19:26:45< vultraz> active = enabled/disabled
20161118 19:26:49< vultraz> selected = clicked/not clicked
20161118 19:27:15< vultraz> I've given it a misleading name
20161118 19:27:23< celticminstrel> Ahhhh.
20161118 19:27:25< celticminstrel> Okay.
20161118 19:27:34< celticminstrel> I keep forgetting this.
20161118 19:27:37< celticminstrel> Okay.
20161118 19:27:39< celticminstrel> So.
20161118 19:27:42< vultraz> so 
20161118 19:27:57< celticminstrel> member.first is the widget?
20161118 19:28:02< celticminstrel> Or the ID?
20161118 19:28:05-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Read error: Connection reset by peer]
20161118 19:28:09< vultraz> no, the value
20161118 19:28:15< celticminstrel> Ah, right.
20161118 19:28:19< vultraz> you can see the function takes T&
20161118 19:28:39-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 19:28:53< vultraz> the part im confused with is how i got the flags to work
20161118 19:29:14< vultraz> it's supposed to reselect an item if the selected one was disabled
20161118 19:29:18< celticminstrel> So if get_value_bool(), you set had_selection=true.
20161118 19:29:22-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161118 19:29:33< vultraz> or the first available item if none were previously selected
20161118 19:30:06< vultraz> so what i wanted was... reselect only if the selection changed or there was no selection previously
20161118 19:30:14< vultraz> but i couldn't figure out how to do that with one flag
20161118 19:30:23< vultraz> so i added a second
20161118 19:30:31< vultraz> and shoved stuff around and it worked...somehow
20161118 19:31:17< celticminstrel> So, if res==false and w.get_value_bool()==true, you set_value_bool(false) and set do_reselect=true... (I think this isn't a good place to use continue, BTW.)
20161118 19:31:52< vultraz> yeah i can change that
20161118 19:31:53< celticminstrel> IOW if the button needs to be disabled and it was selected, you deselect it and set do_reselect.
20161118 19:32:14< vultraz> right
20161118 19:32:22< vultraz> and that all works perfectly fine
20161118 19:32:26< celticminstrel> So do_reselect means, "The currently selected button has been disabled".
20161118 19:32:36< vultraz> except an option won't be selected if none were before with only that flag
20161118 19:32:46< celticminstrel> And "had_selection" means "there was an enabled button", which should always be true,
20161118 19:32:48< vultraz> because do_reselect is never true in that case
20161118 19:32:54< celticminstrel> (Except on first run.)
20161118 19:32:58< vultraz> no, it can be false
20161118 19:33:05< vultraz> if all options are disabled
20161118 19:33:12< celticminstrel> s/enabled/selected/
20161118 19:33:21< celticminstrel> Ah, right.
20161118 19:33:51< celticminstrel> Do you really need the had_selection flag?
20161118 19:33:58< vultraz> I don't know
20161118 19:34:01< vultraz> do I?
20161118 19:34:05< vultraz> can i make it work with one flag?
20161118 19:34:08< vultraz> if so tel me
20161118 19:34:10< vultraz> tell
20161118 19:34:32< celticminstrel> Doesn't do_reselect by itself tell you whether you need to reselect?
20161118 19:34:48< celticminstrel> Well, okay, I guess there's one case where do_reselect is true but you don't need to reselect.
20161118 19:35:05< celticminstrel> But in that case your reselection code just won't select anything.
20161118 19:35:07< vultraz> I always run into one of two problems:
20161118 19:35:24< vultraz> * no buttons selected, and then none are selected since none were previously
20161118 19:35:26< vultraz> OR
20161118 19:35:43< vultraz> * a button was selected, and then a second one ends up selected
20161118 19:35:51< celticminstrel> Hmm.
20161118 19:36:17< celticminstrel> Okay, suppose you start with the assumption that you do need to reselect ("bool do_reselect = true").
20161118 19:36:37< celticminstrel> Then, once you find the current selection, if res==true, set do_reselect=false.
20161118 19:38:47< celticminstrel> Does that make sense?
20161118 19:39:04< celticminstrel> That seems like it would fix both problems you mentioned.
20161118 19:39:10< vultraz> hmmm
20161118 19:39:16< vultraz> let us see
20161118 19:40:58< vultraz> good god you're a wizard 
20161118 19:41:14< vultraz> ty ty
20161118 19:41:19< vultraz> now, for some sleep >_>
20161118 19:42:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161118 19:42:56< vultraz> (new code http://pastebin.com/QisAhuPj )
20161118 19:43:02< vultraz> can probably simplify it a little
20161118 19:43:06< vultraz> but too tired right now
20161118 19:43:55< celticminstrel> Yeah, you should be able to set do_reselect only once instead of twice within the loop.
20161118 19:44:05< celticminstrel> Also, bad continue.
20161118 19:45:17< Soliton> the unchecked dynamic_cast looks fishy.
20161118 19:45:45< vultraz> fishy?
20161118 19:45:49< celticminstrel> In practice, every selectable_item is also a styled_widget.
20161118 19:46:08< celticminstrel> Even though the two classes have no relationship.
20161118 19:46:27< celticminstrel> So while it may be fishy, it's not going to fail.
20161118 19:46:39< celticminstrel> (Unless of course someone adds a selectable_item that's not a styled_widget.)
20161118 19:47:59< Soliton> interesting design.
20161118 19:48:28< celticminstrel> selectable_item is kinda like an "interface", though I think it does have some concrete methods.
20161118 19:54:17< tad_carlucci> I'm tracking down game events. At present I am looking at menu events. I can see them coming from Lua. Where I have a question is why all the work to handle loading them from saved games when the function which saved the game specifically did NOT save them. Am I missing something or is the legacy cruft?
20161118 19:55:01< celticminstrel> Menu items are supposed to be saved as [menu_item] tags in the saved game, if I recall correctly.
20161118 19:55:27-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Remote host closed the connection]
20161118 19:55:42< celticminstrel> They're definitely saved somehow in 1.12, since they can persist from one scenario to the next.
20161118 19:55:51< vultraz> there's also a menu_item_x (where x = id) event..
20161118 19:55:58< celticminstrel> I don't know many details about this.
20161118 19:56:03< celticminstrel> vultraz: That's different.
20161118 19:56:12< vultraz> ah
20161118 19:56:26< celticminstrel> It's just a normal event, so it would be saved in the same way.
20161118 19:58:47< vultraz> right
20161118 19:59:26< tad_carlucci> No. It's so NOT a "normal" event. It's NOT saved by the function which saves normal events .. that would convert them to [event] tags.
20161118 20:00:00< celticminstrel> Menu items, yeah, aren't quite the same.
20161118 20:00:33< celticminstrel> They're supposed to be converted to [menu_item] tags, I think.
20161118 20:00:45< tad_carlucci> So there's something else going on for the WML menu side. Probably doesn't ever set "is menu item" because it's implied by being inside a menu so it's never checked.
20161118 20:02:04< tad_carlucci> There is a "set menu items" (note: plural) which is not on the call-tree for any code checking "is menu item". I s'pose I should read through that.
20161118 20:03:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 20:05:35-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 20:22:57-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Read error: Connection reset by peer]
20161118 20:23:41-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 20:24:30-!- gfgtdf__ [~chatzilla@x4e368bbc.dyn.telefonica.de] has joined #wesnoth-dev
20161118 20:24:34-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161118 20:24:40-!- gfgtdf__ is now known as gfgtdf
20161118 20:30:10-!- gfgtdf_ [~chatzilla@x4e368bbc.dyn.telefonica.de] has joined #wesnoth-dev
20161118 20:31:32-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161118 20:31:36-!- gfgtdf_ is now known as gfgtdf
20161118 20:39:57-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Ping timeout: 240 seconds]
20161118 20:48:13-!- JyrkiVesterinen [~JyrkiVest@87-92-31-135.bb.dnainternet.fi] has quit [Quit: .]
20161118 20:48:28-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161118 20:51:01-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161118 20:51:52-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 49.0.2/20161019084923]]
20161118 20:53:11-!- irker885 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161118 20:58:00-!- Shiki [~Shiki@141.39.226.226] has quit [Quit: Verlassend]
20161118 21:51:43< celticminstrel> Hmm, I don't see any clear causes for the ~O(100%) bug in the log...
20161118 21:53:54< celticminstrel> The math looks correct in the mod parser, implying that ~O(1.0) has the same problem.
20161118 22:00:20< celticminstrel> So the issue appears to be that someone (vultraz?) descided to store the output of ftofxp in a Uint8 instead of a fixed_t (which is a typedef of int32_t).
20161118 22:00:34< celticminstrel> ftofxp(1.0) turns out to be 256, so it overflows to 0.
20161118 22:02:08< celticminstrel> I kinda question the use of fixed-point here at all...
20161118 22:05:29< tad_carlucci> Is it possible to use [fire_event] to fire the [command] from a [menu_item] ???
20161118 22:06:55< celticminstrel> I doubt it.
20161118 22:07:30-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161118 22:07:40< zookeeper> celticminstrel, you checked 6797e82414fed ?
20161118 22:07:57< zookeeper> tad_carlucci, probably not
20161118 22:08:07< celticminstrel> There is a Lua function to trigger a menu event, I think (undocumented), but pretty sure it's not used by [fire_event]/
20161118 22:08:12< celticminstrel> zookeeper: Think so, yeah.
20161118 22:08:42< celticminstrel> My guess is that the error snuck in due to vultraz integrating the content of the previously-removed function into the body of the ~O() implementation.
20161118 22:09:22< celticminstrel> The removed check in the later fixup should have been an alarm bell, I guess.
20161118 22:09:58< celticminstrel> I'm not quite sure what the proper fix here is.
20161118 22:10:01< tad_carlucci> Logically, is should be. The [menu_item][command] gets an id which is semantically identical to [event]id= .. and I know there is no check for "is menu item" .. I suppose I need to actually test it.
20161118 22:10:16< tad_carlucci> zookeeper, If I find it is possible, should I make it no longer possible?
20161118 22:10:53< celticminstrel> tad_carlucci: It shouldn't've been possible prior to adding fire_event_by_id, at least.
20161118 22:11:11< zookeeper> if it somehow magically happens to be possible right now, i see no reason to specifically disallow it
20161118 22:11:12< tad_carlucci> And therein lies the question.
20161118 22:11:42< celticminstrel> But is it not possible to have an [event] and [menu_item] with the same ID?
20161118 22:12:41< tad_carlucci> celticminstrel, That is not the question. The question is: is it possible to know the id for the [command] in [menu_item] for use in [fire_event_by_id]?
20161118 22:13:24< tad_carlucci> celticminstrel, But that is a good question, too. Is it possible to define an [event]id= which matches the id assigned to [menu_item][command] and if so, who wins?
20161118 22:16:54< zookeeper> so what exactly prompted this question in the first place? why are you assuming some kind of equivalency of any kind between evens and menu items?
20161118 22:17:01< zookeeper> events, even
20161118 22:17:11< celticminstrel> Because they're stored in the same place by the game.
20161118 22:17:15< celticminstrel> (The handlers for them.)
20161118 22:17:46< tad_carlucci> zookeeper, Because I'm code-reading and there is not "some kind of equvalency" there is identity. They are the same. The difference is the flag "is menu item" within the object.
20161118 22:18:00< zookeeper> right
20161118 22:18:24-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161118 22:18:40-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161118 22:20:11< tad_carlucci> But there are two ways to scope them differently. One is using the flag; which leads to id collision. The other is the 'manager' objects which 'owns' them. If the [event] manager is not the same as the [menu_item] manager than there is no collision and you cannot fire the menu event with [fire_event*]
20161118 22:20:42< celticminstrel> Sounds reasonable.
20161118 22:21:20< tad_carlucci> Right now I'm just tracking down 'is menu item'; where it's used and where it comes from.
20161118 22:21:20 * celticminstrel notes that there's only [fire_event], but backed by two Lua calls fire_event and fire_event_by_id.
20161118 22:23:18-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Remote host closed the connection]
20161118 22:24:51< tad_carlucci> Here's why I'm doing this. I'm wondering if the mess I'm seeing when I try to eliminate smart_list might best be handled by booting it all to the curb and doing a proper design and clean implementation. But, to do that, I need to understand the difference between an [event] and a [menu_item][command]. And then I need to understand the manager message. It's slow going because it's such spaghetti.
20161118 22:25:18-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161118 22:27:29-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 22:27:56-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20161118 22:27:57-!- wedge010 is now known as wedge009
20161118 22:32:14-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has joined #wesnoth-dev
20161118 22:33:52< gfgtdf> vultraz: is there a lua interface for the unit preview panel widget ? Meaning can i do like wesnoth.set_dialog_value(wesnoth.get_unit(x,y), "previw_panel_id")
20161118 22:34:43< gfgtdf> tad_carlucci: you cna know the name of the event generated by the menu uitems
20161118 22:34:52-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Read error: Connection reset by peer]
20161118 22:35:18< gfgtdf> tad_carlucci: in fact i do ahve addition event with name="menu_item_<item_id>" or similar to add additional eventhandlers to a menu item
20161118 22:35:25-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 22:35:32< gfgtdf> tad_carlucci: in my addon "scenario with robots"
20161118 22:36:50< tad_carlucci> gfgtdf, So you're using [event] to add and ADDITIONAL process to fire when the menu item fires?
20161118 22:38:04-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 22:38:16-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20161118 22:38:21< gfgtdf> tad_carlucci: i add the menu item here: https://github.com/gfgtdf/Scenario_with_robots/blob/master/lua/mp_era.lua#L5 and do the event handling here: https://github.com/gfgtdf/Scenario_with_robots/blob/master/lua/mp_era.lua#L15
20161118 22:39:23< gfgtdf> tad_carlucci: where the add_event_handler function does the same as the one exported from mainlines on_event.lua file
20161118 22:39:25-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161118 22:39:37< celticminstrel> gfgtdf: That's different.
20161118 22:40:01< gfgtdf> celticminstrel: what is different
20161118 22:40:06< celticminstrel> That's an event triggered by selecting the menu item, to add variable actions in addition to the [command] in the menu item.
20161118 22:40:29< gfgtdf> celticminstrel: yes thats what i said
20161118 22:40:49< celticminstrel> My impression is that that's separate from the pseudo-event that executes said [command].
20161118 22:40:51< tad_carlucci> Nah. Except it's Lua instead of WML, it's exactly what I was wondering about.
20161118 22:42:16< celticminstrel> Oh.
20161118 22:42:29< celticminstrel> [Nov 18@5:36:50pm] tad_carlucci: gfgtdf, So you're using [event] to add and ADDITIONAL process to fire when the menu item fires?
20161118 22:42:29< celticminstrel> ^ an additional, right?
20161118 22:42:52< tad_carlucci> Basically, the examples he gave are a [menu_item] with no [command] and adding an [event] to implement the missing [command]
20161118 22:43:00< celticminstrel> Right.
20161118 22:43:15< tad_carlucci> celticminstrel, correct // additional to 'none' in this case
20161118 22:43:18< celticminstrel> Which I think is different from providing the [command].
20161118 22:43:23< gfgtdf> tad_carlucci: norte that on_event doesnt create wml [event]s but instead used the wesnoth.game_events.on_event callback, but ofc he same coudl be done by creating [event]
20161118 22:43:40 * tad_carlucci nods.
20161118 22:43:44< gfgtdf> s/he(the
20161118 22:43:55< tad_carlucci> I can see that. Been reading the C++ for those functions for two days now.
20161118 22:45:28< tad_carlucci> Given he can do this, there is no reason he could not add more. The confusion is it's id= for the [menu_item] but that maps to name= for [event]
20161118 22:46:11< tad_carlucci> ^ *i think* .. need to check that
20161118 22:48:08< tad_carlucci> And, I think the reason this works is because he's using Lua. I'd expect it to work in WML, too, but I'm thinking there's a problem with how it would save/load so it may not play nice with that part of the engine if you used WML. But that's a solvable problem :P
20161118 22:50:23< tad_carlucci> So, what I've learned is there truely is no difference between [event] and [menu_item][command] other than one sets "is_menu_item" so it's saved as a [menu_item][command] instead of an [event].
20161118 22:50:35< gfgtdf> vultraz: i think a lua interface for the unit prewie panel woudl be quite useful for those widgets set_dialog_value shodul accept both unit userdatas and unittype userdatas
20161118 22:51:42< gfgtdf> tad_carlucci: note that when relaoding the order of the evnet might differ if the aditional [event] was added after the [set_menu_item] since the laoding code afaik always adds the menu item event last.
20161118 22:52:04-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Read error: Connection reset by peer]
20161118 22:52:22< gfgtdf> tad_carlucci: in particular this could cause OOS in replays.
20161118 22:52:47-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has joined #wesnoth-dev
20161118 22:52:52< zookeeper> tad_carlucci, one thing to keep in mind is that _if_ [fire_event] was able to fire menu items, it's pretty ambiguous in which circumstances it should succeed. mainly whether the menu item's [filter_location] and [show_if] should matter.
20161118 22:53:04< tad_carlucci> gfgtdf, Not surprised. And I'd expect that it would cause OOS. And it's still solvable.
20161118 22:53:27< gfgtdf> zookeeper: i don't think they matter here
20161118 22:54:04< gfgtdf> zookeeper: note that you need to do [fire_event] "menu_item_<item_id>"
20161118 22:54:20< tad_carlucci> gfgtdf, That's the issue.
20161118 22:54:27< zookeeper> gfgtdf, ok, so you can fire them via [fire_event] already?
20161118 22:54:38< gfgtdf> zookeeper: my ques woudl be yes but i didnt test it
20161118 22:55:09< tad_carlucci> And since we can use [event] to cause additional processing on the [menu_item] we have (1) sequencing issues and (2) a problem if [fire_event] fires the menu event.
20161118 22:55:38< gfgtdf> how is there  aproblem if [fire_event] fires the menu event
20161118 22:56:08< tad_carlucci> Consider what that means wrt first_time_only
20161118 22:56:37< gfgtdf> tad_carlucci: you mean [command] first_time_only=yes ?
20161118 22:56:57< tad_carlucci> sure. or a few events, some with and some without ... 
20161118 22:58:11< gfgtdf> tad_carlucci: i still dont see how this is an problem, if they have first_time_only=yes they get excuted ony one , unrelated to whether it's fired by menu item click or via [fire_event]
20161118 22:59:11< tad_carlucci> Assume all [event] and [command] are first-time-only, use [fire_event] ... you'll have a "does nothing" menu item appear when you right click because it's handlers have all been removed 
20161118 22:59:37< celticminstrel> gfgtdf: Is firing "menu_item_id" really the same as selecting the menu item with ID "id" when that menu item has a [command]?
20161118 22:59:41< tad_carlucci> Logically, the [menu_item] should go when its last [command]/[event] does
20161118 22:59:53< gfgtdf> tad_carlucci: thats woudl also be the case when you lcik on it when it has firt_time_onyl=yes
20161118 22:59:54< tad_carlucci> But I'll be it doesnot.
20161118 23:00:14< celticminstrel> BTW, menu items are presumably implicitly (maybe forced) first_time_only=no, right?
20161118 23:00:25< zookeeper> celticminstrel, if it works at all, then it's very crippled since of course you can't pass any location info etc which usually is needed for any menu item to be able to do anything
20161118 23:00:35< gfgtdf> celticminstrel: not sure how exctly it behaves with filter
20161118 23:00:51< celticminstrel> gfgtdf: Well, it's firing an event, so of course it would honour the event's filters.
20161118 23:01:01< celticminstrel> gfgtdf: But, it probably doesn't even know about the menu item.
20161118 23:01:15< celticminstrel> gfgtdf: So I doubt it'd account for any of the menu item's filters.
20161118 23:01:27< tad_carlucci> zookeeper, Oh, there's probably all sorts of breakage, yes. But remember the [menu_event] filters are OUTSIDE the [command]/[event] block
20161118 23:01:36< gfgtdf> tad_carlucci: (at last i don't think thay there are (many) people that really use [fire_event] menu_item_x, if you want to do complcated menu item stuff you can always use [fire_event] inside the [command] and use well defined dbehaviour instead of menu_item_x name hackery)
20161118 23:01:46< celticminstrel> Note that [command] and [event] are not equivalent.
20161118 23:01:51< gfgtdf> behaviour 
20161118 23:01:55< celticminstrel> [command] only contains ActionWML IIRC
20161118 23:02:03< celticminstrel> [event] also contains additional tags and attributes.
20161118 23:02:07< tad_carlucci> celticminstrel, correct
20161118 23:02:37< celticminstrel> [event] probably should have required a [command] subtag for the WML code.
20161118 23:02:47< celticminstrel> Then the filters and attributes would be logical separated.
20161118 23:02:52< zookeeper> perhaps one should first establish for certain what the current behavior is exactly... it sounds like no one knows
20161118 23:02:59< gfgtdf> celticminstrel: that the wiki only mentions action wml doesnt mean that the other tags (filters) are ignored
20161118 23:03:26< celticminstrel> If it's possible for wesnoth.fire_event() to fire a menu item, I think that possibility should be removed.
20161118 23:03:38< celticminstrel> Possibly shifted to a separate wesnoth.fire_menu_item().
20161118 23:03:56< celticminstrel> (Does that currently exist? I know there's some undocumented API relating to menu items.)
20161118 23:04:02< tad_carlucci> I can tell you this .. once the [event]/[command] is created they are identical. So if [event] supports filters inside the block so does [command] .. the question is not the processing, it's whether the parser will let [command] have filters and such
20161118 23:04:58< celticminstrel> tad_carlucci: I think the parser for [command] is specially equipped to ignore the [event] filters.
20161118 23:05:07< tad_carlucci> celticminstrel, hold off on thinking about that. I might be able to render the issues moot in a while.
20161118 23:05:28< celticminstrel> And I think that when an [event] is added, the filters are handled separately.
20161118 23:06:27< celticminstrel> A [command] block is passed to the Lua handle_event_commands function, implemented in data/lua/wml-utils.lua.
20161118 23:06:46< celticminstrel> (Well, technically it also passes through wesnoth.wml_actions.command.)
20161118 23:06:56< celticminstrel> (But that function does nothing but forward to handle_event_commands.)
20161118 23:07:05< tad_carlucci> At this point I'm gathering information and doing proofs-of-concept work. So far it's holding together .. I can fire events immediately, queue them, all the happy stuff. But to this point I'd ignored menu items and need to add that to the POC code and design.
20161118 23:08:05< celticminstrel> If you're fiddling with queued events you might want to verify that [allow_undo], [on_undo]. [on_redo] also work.
20161118 23:08:26 * celticminstrel slasp a comma after [on_undo].
20161118 23:08:27< tad_carlucci> celticminstrel, That is only true if the [command] runs from a menu click/hot key. If [fire_event] hits it (and it should) the [command] part is gone and the engine thinks it read [event]
20161118 23:08:29< celticminstrel> ^slaps
20161118 23:09:06< celticminstrel> tad_carlucci: IIRC, [event] is passed to the same handler as [command].
20161118 23:10:09< tad_carlucci> celticminstrel, But the "command" is added back when it's passed to Lua. The fact Lua simply punts it to the same handler is "current implementation"
20161118 23:10:32< celticminstrel> I'm not sure I get what you're saying here.
20161118 23:11:19< tad_carlucci> When you clikc/hotkey the menu item it calls Lua wml_action("command", config)
20161118 23:11:59< tad_carlucci> What Lua does with it is up to Lua.
20161118 23:13:17< celticminstrel> And Lua doesn't do anything with the filters, because at that point they should've already been considered.
20161118 23:13:35< tad_carlucci> BTW, no, it checks for first_time_only and deletes the data structure BEFORE it does that Lua call, and the config it passes to lua is a vconfig copy
20161118 23:14:24< celticminstrel> Sorry, what's your "no" denying?
20161118 23:14:45< tad_carlucci> That menu events are implicityl first-time-only.
20161118 23:15:07< gfgtdf> tad_carlucci: they are implicitly not first-time-only
20161118 23:15:24< celticminstrel> The event defined by [set_menu_item][command] is, at least.
20161118 23:15:27< tad_carlucci> I presume that since the C++ checks and deleted
20161118 23:15:38< gfgtdf> tad_carlucci: i think one of the readon why it removed theventhandler  before is that the actionwml codul recursiveley fire the event again
20161118 23:16:21< celticminstrel> gfgtdf: That shouldn't matter?
20161118 23:16:36< celticminstrel> Assuming "firing an event" just means "adding it to the queue".
20161118 23:17:00< celticminstrel> The handler just needs to be removed at some point while processing the current queued event.
20161118 23:17:09< celticminstrel> Before moving on to the next queued event.
20161118 23:17:20< celticminstrel> (Of course that only applies to first_time_only=yes as well.)
20161118 23:17:48 * celticminstrel finds this conversation fairly confusing.
20161118 23:18:12< tad_carlucci> celticminstrel, Welcome to BfW programming.
20161118 23:18:29< gfgtdf> celticminstrel: [fire_event] fires the event directly (instead of firing it after the current event has finished)
20161118 23:19:15< gfgtdf> not as confusing as mp sync :)
20161118 23:19:27< celticminstrel> Why?
20161118 23:22:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 250 seconds]
20161118 23:22:26< gfgtdf>  remember talking about strange corner cases of my sync liek "coudl thice code cause OOS in case that 2 players are in 2 diffenet scenarios of a mp campaigns any one player leaves while the other waits for an advancement choice"
20161118 23:22:27< tad_carlucci> If you think it's confusing to talk about, you should try reading the code. The only way I can track what's being passed where it to force a compile-error for the datum and let the compiler tell me.
20161118 23:24:09-!- mjs-de [~mjs-de@x4db541d1.dyn.telefonica.de] has joined #wesnoth-dev
20161118 23:25:03< gfgtdf> tad_carlucci: i actual think the code got quite a bit easier with the removal of the wmi_pager
20161118 23:25:08< tad_carlucci> I tracked 'is_menu_item' down 8 or so levels to where it's actually checked, then back up 12 levels only to find ALL of the 20 or so functions ONLY happen if you added the menu item using Lua.
20161118 23:26:10< gfgtdf> tad_carlucci: i think all menu_items are added via lua somehow
20161118 23:27:21< tad_carlucci> gfgtdf, No. They're loaded during the scenario load. The lua function is only run if called from Lua.
20161118 23:27:43-!- gfgtdf_ [~chatzilla@x4e368bbc.dyn.telefonica.de] has joined #wesnoth-dev
20161118 23:28:55< tad_carlucci> load --> first time or from a save game or replay
20161118 23:29:43< celticminstrel> So in other words [set_menu_item] triggers a Lua API call, but loading a [menu_item] does not.
20161118 23:29:58< gfgtdf_> tad_carlucci: hmm yes but then there usually were addes with lua before the game was saved or in a previous scenario
20161118 23:30:40-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
20161118 23:31:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161118 23:32:15-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has joined #wesnoth-dev
20161118 23:34:51-!- gfgtdf_ [~chatzilla@x4e368bbc.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161118 23:35:49-!- gfgtdf_ [~chatzilla@x4e36840a.dyn.telefonica.de] has joined #wesnoth-dev
20161118 23:37:01-!- prkc_ [~prkc@46.166.190.224] has joined #wesnoth-dev
20161118 23:37:24< tad_carlucci> I presume "wmi_pager" is something to do with displaying menu items? I don't see it involved so far with the event processing. But it might be the reason for the complexity nonetheless.
20161118 23:37:33-!- gfgtdf [~chatzilla@x4e368bbc.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
20161118 23:37:43-!- gfgtdf_ is now known as gfgtdf
20161118 23:40:19< celticminstrel> tad_carlucci: It was a way to fit more than 7 events in the menu or something.
20161118 23:40:32< celticminstrel> It was removed at some point IIRC.
20161118 23:41:31-!- prkc_ [~prkc@46.166.190.224] has quit [Remote host closed the connection]
20161118 23:41:31-!- prkc [~prkc@46.166.190.224] has quit [Remote host closed the connection]
20161118 23:41:40< tad_carlucci> Ah. Well when it comes to the current code 'it is what it is' before I can consider 'repair or replace' I need to understand it.
20161118 23:41:42-!- prkc [~prkc@46.166.190.224] has joined #wesnoth-dev
20161118 23:45:07-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161118 23:45:07-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20161118 23:53:32-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:556f:f0da:4513:51b2] has quit [Remote host closed the connection]
20161118 23:54:38-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20161118 23:59:10-!- irker405 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161118 23:59:10< irker405> wesnoth: Wedge009 wesnoth:master 5ab0c22300b2 / projectfiles/VC12/ (wesnoth.vcxproj.filters wesnothlib.vcxproj wesnothlib.vcxproj.filters): Added spirit_po to wesnothlib VC project. https://github.com/wesnoth/wesnoth/commit/5ab0c22300b21a8a8b215b9fe9a3530cac0dd64e
--- Log closed Sat Nov 19 00:00:24 2016