--- Log opened Thu Jan 28 00:00:14 2016
20160128 00:08:06-!- Appleman1234 [~Appleman1@KD119104016226.au-net.ne.jp] has joined #wesnoth-dev
20160128 00:08:31-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160128 00:13:51< vultraz> if anyone wants to do a review of 581 sometime you now can 
20160128 00:15:53-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160128 00:30:02-!- SpoOkyMagician [~chatzilla@cpe-74-136-45-198.kya.res.rr.com] has quit [Quit: Zz. -_-]
20160128 00:31:09< gfgtdf> vultraz: im getting unicorn error at github.
20160128 00:33:14< shadowm> lolwhat
20160128 00:34:22< shadowm> Maybe China is throwing a tantrum again.
20160128 00:38:13< vultraz> hah!
20160128 00:42:54-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160128 00:46:38-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160128 00:49:06-!- SigurdFD [~SigurdFD@dynamic-acs-72-23-109-141.zoominternet.net] has joined #wesnoth-dev
20160128 00:52:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160128 00:54:01-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160128 00:55:28-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160128 00:57:27< vultraz> hopefully it's not down too long
20160128 00:58:07< vultraz> gfgtdf: I wonder if maybe you can fix a few of the remaining tree view bugs before we merge 581
20160128 00:58:20< vultraz> like the toggle button crash and the incorrect scroll_label handling
20160128 00:58:54< gfgtdf> vultraz: i dont think have scroll_labels inside treeviews in my todo list, and i dont know wbaout the toggle button crash.
20160128 00:59:33< gfgtdf> vultraz: you think that connect to github via git application still works ?
20160128 01:00:10< shadowm> Why not try for yourself?
20160128 01:00:31< vultraz> seems to
20160128 01:00:53< shadowm> vultraz: Can you give me the remote branch name?
20160128 01:01:09< vultraz> "prefs_dialog_refactor"
20160128 01:02:34< shadowm> shadowm@nanacore:~/src/wesnoth% git cherry master | wc -l
20160128 01:02:34< shadowm> 55
20160128 01:02:38< shadowm> Okay, that's a lot of commits.
20160128 01:02:58< vultraz> Yup
20160128 01:03:16< shadowm> ... You preserved my initial commits verbatim.
20160128 01:04:51< vultraz> yup
20160128 01:04:54< shadowm> Your own commits also seem to include WIP noise.
20160128 01:05:12< gfgtdf> hmm commandline git tells me: fatal: unable to access 'https://github.com/wesnoth/wesnoth/': The requested URL returned error: 500
20160128 01:05:22< shadowm> Try SSH.
20160128 01:05:48< vultraz> Everything was committed in a process, and I don't know how much it's worth trying to rebase everything into little packets 
20160128 01:05:56< shadowm> "Little packets"?
20160128 01:06:08< shadowm> The fact that it looks like little packets right now is what's going to be aa problem. :p
20160128 01:06:12< vultraz> er, big packets 
20160128 01:07:15< vultraz> the foremost thing is feedback on the design
20160128 01:07:25< vultraz> then feedback on the code comes later
20160128 01:07:39< shadowm> Nope, I'm going to look at the code first and the design later.
20160128 01:07:39-!- mjs-de [~mjs-de@f048192075.adsl.alicedsl.de] has quit [Remote host closed the connection]
20160128 01:07:56< vultraz> ok then :D
20160128 01:08:07< shadowm> Because I don't trust you with C++ yet.
20160128 01:08:33< vultraz> I used a lot of templates
20160128 01:09:05< vultraz> off to get lunch, bb in 20
20160128 01:09:49< shadowm> -tpreferences::tpreferences()
20160128 01:09:51< shadowm> +tpreferences::tpreferences(display* disp) :
20160128 01:10:39< shadowm> Maybe I'll cut to the chase and look at the full diff instead of browsing the commit log.
20160128 01:11:04< shadowm> For my sanity.
20160128 01:16:29< shadowm> God dammit I need a diff tool that doesn't suck.
20160128 01:20:48< shadowm> inline void make_dialog_callback_helper(const dialog_member_func_type & t, twidget & caller) {
20160128 01:20:51< shadowm>     twindow * window = dynamic_cast<twindow *>(caller.get_window());
20160128 01:20:55< shadowm> Who wrote this?
20160128 01:21:06< shadowm> caller is a twidget. twidget::get_window() always returns a twindow*.
20160128 01:21:12< shadowm> The dynamic_cast is redundant.
20160128 01:21:25< shadowm> (This is src/gui/dialogs/helper.hpp line whatever.)
20160128 01:21:58-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 265 seconds]
20160128 01:23:24< shadowm>     static std::string bool_to_display_string(bool value)
20160128 01:23:56< shadowm> This should be a non-static member of an anonymous namespace if you are going to attribute code to me.
20160128 01:24:31< shadowm> Same thing goes for every other static function in sight.
20160128 01:26:00< shadowm> int_to_accl_speed/accl_speed_To_int are ridiculous. I said we didn't need fancy maths, just a switch block would've sufficed.
20160128 01:26:42< shadowm> static void set_res_list(tcombobox& res_list, CVideo& video)
20160128 01:26:53< shadowm> Look, you don't need to abbreviate everything.
20160128 01:27:16< shadowm> I'd rather have an_extremely_long_function_name_that_is_meaningful than ambiguous_abbr_func.
20160128 01:28:40< shadowm> The for loop in set_res_list() could've been a FOREACH loop since the subscript goes unused for anything other than trivial reads.
20160128 01:29:39< shadowm> That'd make the code considerably less verbose. For a human. At the cost of increased compile-time complexity because Boost.Foreach is expensive like that.
20160128 01:29:51< shadowm> (But that didn't stop the dozen devs who decided to deploy it everywhere over the years, did it.)
20160128 01:30:55< shadowm> Oh, and disregard anything I say about legacy code that you just cut-and-pasted around.
20160128 01:31:29< vultraz> shadowm: iceiceice wrote make_dialog_callback_helper
20160128 01:31:55< shadowm> Well what I said about the dynamic_cast won't stop being any less true regardless of who wrote it.
20160128 01:32:22< vultraz> Alright
20160128 01:32:43< vultraz> Yes, I still need to update some of the legacy code in set_res_list and initialize_friends_list
20160128 01:33:54< iceiceice> vultraz, fwiw i don't think i introduced new dynamic casts, i just restructured part of the code from the earlier dialog callback function
20160128 01:34:09< iceiceice> so maybe check the original "dialog_callback" whatever function? maybe that also has a redundant cast
20160128 01:34:10< vultraz> well then, the old code is wrong?
20160128 01:34:18< shadowm> Okay, explain to me why setup_single_toggle() is a template, vultraz.
20160128 01:34:48< shadowm>     template <typename T> void setup_single_toggle(const std::string& widget_id, const bool start_value, boost::function<void(bool)> callback, T& window);
20160128 01:36:08< vultraz> line 705 uses that function but passes a tgrid reference
20160128 01:36:24< shadowm> Then why is the parameter called window?
20160128 01:37:36< vultraz> will change
20160128 01:37:45< vultraz> (and in similar functions)
20160128 01:38:50< vultraz> BTW, I thought there was no difference between an anon namespace and static
20160128 01:39:36< shadowm> There is a technical difference.
20160128 01:39:49< gfgtdf> vultraz: did you try changing the parameter to twidget instead of T ?
20160128 01:39:53< shadowm> I don't remember what it is and it's irrelevant. It's the linguistic difference that matters to me.
20160128 01:40:06< iceiceice> shadowm, it matters for linking
20160128 01:40:37< iceiceice> anonymous namespace is basically "extra safe" with regards to the possibility of a symbol name collision with some other compilation unit
20160128 01:41:15< shadowm> Uh, I didn't know static functions could ever collide.
20160128 01:41:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160128 01:42:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 01:43:03< shadowm> vultraz: tpreferences::setup_combobox(); why is options passed by value?
20160128 01:43:16< iceiceice> i have to look at the rules again but that was my understanding of it
20160128 01:43:30< shadowm> (It's a std::pair<std::vector<std::string>, std::vector<std::string> >.)
20160128 01:44:13< vultraz> Oversight. Fixed. 
20160128 01:44:23< shadowm> Also, the thing you are doing with the commas in multi-line expressions is usually only reserved for constructor lists.
20160128 01:44:29< vultraz> (haven't pushed anything yet, compiling a cleanup commit) 
20160128 01:44:39< shadowm> It looks just weird elsewhere because there isn't a leading token.
20160128 01:44:59< shadowm> Just whitespace.
20160128 01:46:18< shadowm> You are using the first grammatical person in Doxygen comments.
20160128 01:46:51< shadowm> And this isn't even a @note or @todo block.
20160128 01:47:23< vultraz> That's the doxygen syntax?
20160128 01:47:33< vultraz> I thought it was a stylized comment block
20160128 01:47:46< shadowm> /** Doxygen comment */
20160128 01:47:56< shadowm> /// Doxygen comment
20160128 01:48:10< shadowm> /**< Doxygen comment for the preceding portion of this line */
20160128 01:48:19< celticminstrel> Or for the line above.
20160128 01:48:21< celticminstrel> I think.
20160128 01:48:29< shadowm> ///< Doxygen comment for the preceding portion of this line
20160128 01:48:43< shadowm> (Note: I hate the triple-slashes form.)
20160128 01:48:47< iceiceice> hmm ok, this is what it is
20160128 01:49:01< celticminstrel> I prefer triple-slashes if it's a one-liner.
20160128 01:49:02< iceiceice> when i have "static int x", it has internal linkage, but it can enter the symbol table as "x"
20160128 01:49:09< celticminstrel> But these things usually aren't.
20160128 01:49:31< vultraz> I prefer double slashes for that
20160128 01:49:42< iceiceice> when its in an anonymous namespace, the compiler is required to mangle the name to prevent a collision
20160128 01:50:08< shadowm> vultraz: // is a single-line C++ comment. Doxygen won't pick it up without the third slash.
20160128 01:50:33< vultraz> I wish I had known this before
20160128 01:50:53< vultraz> I've actually googled trying to figure out what these different comment styles were and couldn't find anything
20160128 01:51:07< shadowm> (Obviously, /// is just a single-line C++ comment that happens to start with a slash. Doxygen's just piggy-backing on C++'s syntax.)
20160128 01:51:10< celticminstrel> I'm sure someone would've told you if you'd asked. :P
20160128 01:51:31< shadowm> /* this is an ANSI C comment block */
20160128 01:51:36< celticminstrel> Look up "doxygen" if you want to know more about how to format Doxygen comments.
20160128 01:52:00< shadowm> /* C doesn't officially support the C++ single-line comment syntax until C99 IIRC. */
20160128 01:52:14< iceiceice> truth is that the doxygen commenting is very spotty across the codebase,
20160128 01:52:17< celticminstrel> Is it my imagination or does Wesnoth have another special comment syntax used to describe GUI2 widgets?
20160128 01:52:21< iceiceice> mordante was the only one who seems to have been religious about it
20160128 01:52:28< shadowm> celticminstrel: Yes.
20160128 01:52:28< vultraz> celticminstrel: that's for the wiki 
20160128 01:52:33< iceiceice> celticminstrel, there is some kind of auto-generated docs for the gui2 stuff
20160128 01:52:47< iceiceice> i dont know who runs it actually, presumably shadowm i guess
20160128 01:52:51< shadowm> The /*wikidoc thing or whatever is mordante's invention.
20160128 01:53:06< shadowm> Yes, I took over since mordante decided to quit.
20160128 01:53:27< shadowm> The documentation was getting stale so I had to figure out how to run his script and fix a few comments along the way.
20160128 01:54:09< shadowm> Personally, I wouldn't worry about it unless you are adding to the framework/widgets. The dialog wiki documentation was really only intended to help theme authors.
20160128 01:54:24< shadowm> And since GUI2 still doesn't officially support themes...
20160128 01:54:42< shadowm> (Yes, _dialogs_ were supposed to be themeable too.)
20160128 01:55:06< shadowm> (That's why find_widget has a variant that doesn't croak if it can't find the requested object.)
20160128 01:55:48< vultraz> [12:28:38]	shadowm	The for loop in set_res_list() could've been a FOREACH  <- you didn't mean BOOST_FOREACH did you
20160128 01:56:02< shadowm> No, I meant FOREACH since this is GUI2 land.
20160128 01:56:25< celticminstrel> That still exists?
20160128 01:56:29< shadowm> In GUI2 land, mordante decided to replace BOOST_FOREACH with FOREACH, which is actually BOOST_FOREACH.
20160128 01:56:51< shadowm> Unless you are using C++11, in which case it's range-for I think.
20160128 01:57:00< vultraz> it's not even used anywhere 
20160128 01:57:15< shadowm> It is used.
20160128 01:57:18< vultraz> wait, it is...
20160128 01:57:22< vultraz> guess i grepped wrong
20160128 01:57:42< shadowm> Okay, no, it's BOOST_FOREACH regardless of the C++ standard in use.
20160128 01:57:59< shadowm> However, it does something really funny with types.
20160128 01:58:29< vultraz> why do almost all its usecases use AUTO :/
20160128 01:58:35< shadowm> It's essentially the equivalent of BOOST_FOREACH(auto& foo, bar) if `auto` was in C++03.
20160128 01:59:04< shadowm> The AUTO symbol is an empty placeholder probably intended to ease the transition to C++11's auto.
20160128 01:59:23< shadowm> Don't ask me why all this crap exists, just deal with it.
20160128 02:00:28< shadowm> tpreferences::setup_radio_toggle() has this parameter:
20160128 02:00:29< shadowm>     std::vector<std::pair<ttoggle_button*, int> >& vec
20160128 02:00:45< shadowm> Are those ttoggle_button* pointers ever _intended_ to be null?
20160128 02:01:16< vultraz> No, that was code I ported from another dialog written by fabi and I intend to try to figure it out more 
20160128 02:01:32< vultraz> since those functions shouldn't be specialized to a certain preference 
20160128 02:01:37< shadowm> And if the answer is yes, why did you choose to first take the address of find_widget()'s result, dereference it every time, and then at the very end actually use the pointer, rather than take it as a reference and only at the very end address-of-it?
20160128 02:01:38< vultraz> but it's very confusing 
20160128 02:01:42< shadowm> (Stylistic question.)
20160128 02:01:55< vultraz> pointers everywhere 
20160128 02:02:19< shadowm> With pointers you should apply the principle of least privilege IMO.
20160128 02:02:28< shadowm> You don't need a pointer? Don't take a pointer until you actually need one.
20160128 02:03:24< celticminstrel> Basically he's telling you to do eg "ttoggle_button& x = find_widget(...)" instead of "ttoggle_button* x = &find_widget(...)".
20160128 02:03:43< vultraz> That I understand
20160128 02:04:16< vultraz> what's confusing is the rest of it
20160128 02:04:23< vultraz> fabi's code is not easy to understand
20160128 02:05:04< shadowm> I'm assuming tpreferences::setup_friends_list() is 100% not yours.
20160128 02:05:23< shadowm> Why? Because it explicitly uses iterators in plain sight.
20160128 02:05:30< vultraz> It's 40% mine 
20160128 02:05:37< shadowm> And that'd be rather out-of-character for you.
20160128 02:06:05< vultraz> the iterator part is not mine
20160128 02:06:35< vultraz> you're right, FOREACH really tidied that loop up
20160128 02:06:41< vultraz> (the resolutions one, I mean)
20160128 02:07:16< shadowm> I mean, I'm not against you learning to use function objects, but...
20160128 02:07:44< shadowm> tpreferences::add_friend_list_entry() could've been implemented using a flag instead of a function object, since AFAICT setter can only be one of two functions.
20160128 02:07:59< shadowm> As opposed to any of an arbitrarily-sized set.
20160128 02:08:06< vultraz> yes, one of two 
20160128 02:08:37< shadowm> (i.e. the "fly meets nuclear bomb" principle.)
20160128 02:09:23< shadowm> It's not that function objects have runtime overhead (they DO but it's not important for this use case), it's declaration of intent.
20160128 02:09:43< shadowm> If your code doesn't need to be generic then there's no point in making it generic.
20160128 02:11:19< shadowm> In other words, sometimes the trivial solution is the best one.
20160128 02:11:34-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160128 02:11:55< shadowm> // TODO: Better to remove from a specific relation? <- what does this mean
20160128 02:12:10< shadowm> Code comments aren't forum threads.
20160128 02:12:48< shadowm> Is there a specific reason initialize_members() exists?
20160128 02:13:06< shadowm> It's very large, but that's only because of the superfluous comments, really.
20160128 02:13:16< shadowm> It could be stuffed into pre_show() just fine.
20160128 02:13:18< vultraz> That was a todo comment from the old code and I wasn't sure what it meant
20160128 02:13:24< vultraz> yes, I can do that\
20160128 02:14:02< shadowm> brb
20160128 02:14:07-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Client Quit]
20160128 02:15:19< vultraz> I'll take your suggestion and reimplement add_friend_list_entry() with a flag
20160128 02:16:15< vultraz> in fact I can do one better
20160128 02:16:34< vultraz> add_friend() and add_ignore are identical except for one word
20160128 02:16:54< shadowm> ... one string value, you mean?
20160128 02:17:34< vultraz> er, yes
20160128 02:17:42< vultraz> the difference is acquaintances[nick] = preferences::acquaintance(nick, "ignore", reason); VS acquaintances[nick] = preferences::acquaintance(nick, "friend", reason);
20160128 02:17:59< vultraz> so can merge this functionality into add_friend_list_entry()  with a flag
20160128 02:18:05-!- prkc [~prkc@51B78693.dsl.pool.telekom.hu] has quit [Remote host closed the connection]
20160128 02:18:18< vultraz> (hopefully)
20160128 02:18:20< shadowm> Or possibly a two-values enum for future-proofing.
20160128 02:18:42< shadowm> Maybe some day we'll get additional categories than just friend and ignore, I don't know.
20160128 02:18:56< shadowm> pet, slave, rival, etc.
20160128 02:19:04< vultraz> oh, damn. acquaintances is static >_> 
20160128 02:19:16 * vultraz moves it
20160128 02:19:38< vultraz> not static anymore
20160128 02:19:40< shadowm>     setup_toggle_slider_pair("sound_toggle_uisfx", "sound_volume_uisfx", [blah blah])
20160128 02:20:09< celticminstrel> What's wrong with it being static?
20160128 02:20:12< shadowm> I feel like at this point you could've chosen to genericize names. Not that I should encourage anyone to do that.
20160128 02:20:17< shadowm> ids.
20160128 02:20:33< vultraz> celticminstrel: can't access it from out-of-file, then, right?
20160128 02:20:41< celticminstrel> Depends where it's static.
20160128 02:20:47< celticminstrel> Is it declared in a class?
20160128 02:20:57< vultraz> anon namespace
20160128 02:21:20< celticminstrel> "static" means three slightly different things depending on where it's used.
20160128 02:21:22< shadowm> I'm starting to get curious about the implementation of boost::ref.
20160128 02:21:47< vultraz> boost::ref is the best thing ever
20160128 02:21:57< celticminstrel> shadowm: I think it's actually as simple as just returning the argument.
20160128 02:22:19< celticminstrel> With template madness forcing the argument to be returned as a reference (provided it was passed as one).
20160128 02:22:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160128 02:22:56< celticminstrel> Same with boost::forward, minus that last requirement. (I assume boost::forward exists.)
20160128 02:23:40< celticminstrel> As I recall, not using boost::ref means the reference decays, so it won't be seen as a reference anymore.
20160128 02:23:59< iceiceice> as nearly as i can tell there's actually not much reason to use an anonymous namespace over static, except that static has too many uses
20160128 02:24:05< vultraz> most of the places I've had to use it have been where I get errors about boost::nocopytable otherwise
20160128 02:24:07< iceiceice> i thought there was more of an advantage to it
20160128 02:24:47< vultraz> (or is it notcopyable?)
20160128 02:24:47< celticminstrel> That use of static was deprecated in C++03, I believe.
20160128 02:24:54< celticminstrel> vultraz: I think it's noncopyable?
20160128 02:25:22< celticminstrel> Or maybe even in C++98?
20160128 02:25:29< iceiceice> celticminstrel, apparently it was deprecated and then they undeprecated it: http://stackoverflow.com/questions/8460327/why-are-anonymous-namespaces-not-a-sufficient-replacement-for-namespace-static
20160128 02:25:42< celticminstrel> I thought they might've done that, but couldn't remember.
20160128 02:26:56-!- gfgtdf_ [~chatzilla@f054154023.adsl.alicedsl.de] has joined #wesnoth-dev
20160128 02:27:39< iceiceice> they really should have come up with a better keyword than "static" to use for class-members
20160128 02:28:14< iceiceice> idk why java decided to copy that
20160128 02:28:20< iceiceice> i guess they just wanted it to be familiar
20160128 02:29:04-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Read error: Connection reset by peer]
20160128 02:29:05< vultraz> I'll make it an enum later
20160128 02:29:11< vultraz> since more than just this would need to use it
20160128 02:29:35-!- gfgtdf [~chatzilla@f054052028.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20160128 02:29:36-!- gfgtdf_ is now known as gfgtdf
20160128 02:29:38-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160128 02:29:54-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Remote host closed the connection]
20160128 02:30:20< shadowm>     tslider* setter_widget = new tslider;
20160128 02:30:37< shadowm> Does ownership of this pointer get transferred somehow?
20160128 02:30:46< shadowm> Or am I looking at a memory leak?
20160128 02:30:47< vultraz> No
20160128 02:31:02< vultraz> I wanted to use a reference but it doesn't work
20160128 02:31:26< shadowm> Because it goes out of scope before the object(s) that use it.
20160128 02:31:53< celticminstrel> Does swap_child transfer ownership?
20160128 02:31:57< shadowm> But your solution was to make it never go out of scope, even after the dialog is destroyed.
20160128 02:32:22< celticminstrel> I have no idea what swap_child actually does.
20160128 02:32:24< shadowm> Good question, vultraz just said no. :p
20160128 02:33:11< vultraz> at least I don't think so
20160128 02:33:56< celticminstrel> Well, I'm bringing it up because it looks like something that could result in the grid taking ownership of it.
20160128 02:34:17< shadowm> It is possible that swap_child() transfers ownership of the old widget to the caller and ownership of the new widget to the callee.
20160128 02:34:35< shadowm> That'd be the sane assumption (but we all know that GUI2 defies logic in some areas).
20160128 02:34:43< celticminstrel> If it transferred ownership of the old widget to the caller, I suspect it would not compile.
20160128 02:35:03< celticminstrel> Because the old widget might not be a tslider.
20160128 02:35:11< vultraz> save_acquaintances Y U BE STATIC 
20160128 02:35:19< vultraz> static, static functions everywhere
20160128 02:35:20< shadowm> celticminstrel: Irrelevant.
20160128 02:35:34< shadowm> twidget* swap_child(const std::string&, twidget*, bool, twidget*);
20160128 02:35:47< shadowm> All widgets are twidget*.
20160128 02:36:11< celticminstrel> Oh, if it returns the old widget, then I could see that working.
20160128 02:36:12< shadowm> The thing is that vultraz ignores the return value.
20160128 02:36:33< shadowm> Iff swap_child is transferring ownership of the old widget to the caller, then that's still a leak source.
20160128 02:36:34< celticminstrel> So if he adds "delete" at the beginning of that line...
20160128 02:37:09< celticminstrel> (And the equivalent lines in other cases.)
20160128 02:37:30< shadowm> I'm too lazy to check exactly who owns what in GUI2 land, so consider that homework for vultraz.
20160128 02:37:33< celticminstrel> (Oh, there's only one of those.)
20160128 02:37:41< vultraz> celticminstrel: two
20160128 02:38:20< celticminstrel> I meant one other besides the slider.
20160128 02:38:24< celticminstrel> So yeah, two.
20160128 02:38:52< shadowm> Ugh, a GSoC-related email to the ML.
20160128 02:39:02< vultraz> swap_grid returns the old widget
20160128 02:39:41< shadowm> Yes, we know, the question is who owns it.
20160128 02:40:13< vultraz> I don't understand pointer ownership
20160128 02:40:17< shadowm> As I said, the normal assumption is that you get to own it (read: destroy it).
20160128 02:40:44< shadowm> But GUI2 is somewhat special, so I wouldn't be surprised if it was actually still owned by whoever created it in the first place.
20160128 02:41:24< shadowm> OTOH even in that case, destroying it should be safe UNLESS the owner dereferences it again first.
20160128 02:41:53< shadowm> vultraz: Think of it like taking your dog for a walk to the park.
20160128 02:42:07< shadowm> If your dog poops, you assume full responsibility for its poop.
20160128 02:42:36< shadowm> Otherwise you may be fined.
20160128 02:42:52< shadowm> In this case, the poop is the memory your program allocates from the heap.
20160128 02:43:26< shadowm> You allocated memory from the heap to create an instance of an object? You take responsibility for releasing that memory by destroying the object as soon as you cease to use it.
20160128 02:43:58< shadowm> OR you may transfer that responsibility to someone else, specifying this in their contract.
20160128 02:44:17< shadowm> In other words, you can transfer responsibility for your dog's poop to your assistant.
20160128 02:45:34< shadowm> Or some other miscellaneous poop control agent that has signed a contract with you that can be accordingly validated by local authorities.
20160128 02:46:30< shadowm> Or maybe your dog only defecates smart poop that releases itself when it goes out of sight (scope).
20160128 02:47:00< shadowm> That'd be one of several smart pointer types, the unique poop.
20160128 02:47:06< shadowm> I mean unique_ptr.
20160128 02:48:08< shadowm> So yeah, whenever you see a pointer, think poop.
20160128 02:48:23< shadowm> That should help you avoid using pointers where not needed.
20160128 02:48:44< shadowm> That's not to say they aren't ever needed. Like poop, sometimes there's no alternative but to get your hands dirty.
20160128 02:50:11< shadowm>     add_pager_row(selector, "advanced.png", _("Advanced section^Advanced"));
20160128 02:50:20< shadowm> Why did you break the translator notes pattern here?
20160128 02:50:32< shadowm> It's still a preferences section.
20160128 02:51:40< vultraz> eh?
20160128 02:51:56< shadowm> Every other entry is prefixed with "Prefs section^".
20160128 02:52:12< vultraz> Oh
20160128 02:52:14< vultraz> huh
20160128 02:53:17< shadowm> tpreferences::post_show() does nothing.
20160128 02:54:19< shadowm> I assume all functions you call to set new preferences value also make the changes happen in-game.
20160128 02:54:40< shadowm> In that case post_show() might as well not be declared.
20160128 02:55:13< shadowm> Wow, I actually made it through that file in finite time.
20160128 02:55:27< vultraz> What do you think overall 
20160128 02:55:53< shadowm> Blah blah blah MAKE_ENUM, I've never used it, no-one's ever told me why it's better than explicit code.
20160128 02:55:58< shadowm> Ignoring it.
20160128 02:56:27< celticminstrel> MAKE_ENUM creates a "rich" enum, which is more like a Java enum.
20160128 02:56:40< shadowm> I don't talk Java.
20160128 02:56:44< celticminstrel> It's good if you want to be able to convert between strings and enum values.
20160128 02:57:14< shadowm> Yeah, but how is it better than writing all the code yourself? Because it's a macro that hides all the implementation details?
20160128 02:57:33< celticminstrel> I guess?
20160128 02:57:35< shadowm> "Hides", because the compiler still gets to see them.
20160128 02:57:53< celticminstrel> The class created by MAKE_ENUM is fairly large, and basically all boilerplate code.
20160128 02:58:16< shadowm> Yeah, just looking at it makes me a bit suspicious.
20160128 02:58:42-!- gfgtdf [~chatzilla@f054154023.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
20160128 02:58:44< shadowm> I'm quite pragmatic when it comes to macros, but even I find a > 100 lines macro rather excessive.
20160128 02:59:21-!- irker549 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160128 02:59:21< irker549> wesnoth: gfgtdf wesnoth:master 3c7dc8edd4db / src/gui/widgets/ (widget.cpp window.cpp window.hpp): adjust widget size to linked size  if linked size was already calculated. https://github.com/wesnoth/wesnoth/commit/3c7dc8edd4db420c8ca811b7ab01e8b36ed6ceff
20160128 02:59:21< irker549> wesnoth: gfgtdf wesnoth:master c402d4cc7eb5 / src/gui/widgets/tree_view_node.cpp: also layout folded treeview nodes https://github.com/wesnoth/wesnoth/commit/c402d4cc7eb562db009503fcb580f1d34131dd22
20160128 02:59:21< irker549> wesnoth: gfgtdf wesnoth:master 498581d41233 / src/unit_helper.cpp: fix colors for unit restitance https://github.com/wesnoth/wesnoth/commit/498581d41233a679fbffd3d285917c9e182a12a0
20160128 02:59:22< irker549> wesnoth: gfgtdf wesnoth:master c978954a43e3 / src/scripting/lua_gui2.cpp: revert to get_dialog_value retuning bools for togglebuttons https://github.com/wesnoth/wesnoth/commit/c978954a43e38ec7a16f0cfcb3a6bf81464115ca
20160128 02:59:24< irker549> wesnoth: gfgtdf wesnoth:master b6d89addd36d / src/scripting/lua_gui2.cpp: fix widget not redrawing after wesnoth.set_dialog_canvas https://github.com/wesnoth/wesnoth/commit/b6d89addd36d4f7df974d5ebf8fd2e9a75e69063
20160128 02:59:38< shadowm> +               column["use_markup"] = "true";
20160128 03:00:03< shadowm> vultraz: How about you make this an option (for the caller) in tsimple_item_selector instead of assuming the input has been sanitized?
20160128 03:00:21< shadowm> Because the input is basically never sanitized, I know that much.
20160128 03:01:01< shadowm> When is it user-provided? :cl comes to mind.
20160128 03:01:18< shadowm> There might be others, currently or in the future.
20160128 03:01:29< vultraz> hmm
20160128 03:01:30< vultraz> ok
20160128 03:01:43< shadowm> As I said about Pango markup before, principle of least privilege. If it doesn't need to use markup, it shouldn't have to ask to not use markup.
20160128 03:03:14< shadowm> Oh boy.
20160128 03:03:39< shadowm> vultraz: src/gui/widgets/tree_view_node.hpp, describe me set_callback_state_change() in pseudocode.
20160128 03:04:36< vultraz> uh, it's so you can add an event when you open a node, close a node, or both
20160128 03:04:42< vultraz> but actually might be bugged
20160128 03:04:45< shadowm> That's not pseudocode, that's documentation.
20160128 03:04:58< shadowm> Okay, let me put it another way: you are probably missing three breaks.
20160128 03:05:05-!- neverEnough [~nEnough@host58-11-dynamic.16-79-r.retail.telecomitalia.it] has quit [Quit: gn8]
20160128 03:05:33< shadowm> switch(foo) { case A: bar(); case B: bat(); case C: baz(); }
20160128 03:05:50< shadowm> if foo == A, this is equivalent to { bar(); bat(); baz(); }.
20160128 03:06:06< shadowm> if foo == B, this is equivalent to { bat(); baz(); }
20160128 03:08:10< vultraz> oh
20160128 03:08:22< shadowm> src/video.cpp:
20160128 03:08:23< shadowm> -       if(modes <= 0) {
20160128 03:08:24< shadowm> +       if (modes <= 0) {
20160128 03:08:32< shadowm> Why is this change even here?
20160128 03:08:49< shadowm> Also note that the left side of the diff is our canonical style, not the right side.
20160128 03:09:12< shadowm> It keeps happening in the same file.
20160128 03:09:36< vultraz> I thought if () {} was the style
20160128 03:09:39< vultraz> not if() {}
20160128 03:09:45< shadowm> No, it's the other way around.
20160128 03:10:05< shadowm> The easiest way to tell is to look at any chunk of GUI2 code written by mordante or me.
20160128 03:10:28< shadowm> +       UNUSED(include_current);
20160128 03:10:44< shadowm> What's the purpose of adding the parameter in CVideo::get_available_resolutions() if nothing ever uses it?
20160128 03:11:04< vultraz> because I was too laze to add an #if to the header
20160128 03:11:04< shadowm> Okay, that's the end of my code review.
20160128 03:11:11< shadowm> #if?
20160128 03:11:15< shadowm> But nothing ever uses it regardless.
20160128 03:11:27< celticminstrel> It's not SDL version dependent then?
20160128 03:12:00< shadowm> Ohh, I see, never mind.
20160128 03:12:10< shadowm> There are two implementations of the same function.
20160128 03:12:29< shadowm> One (under SDL 2.0) uses the argument, the other doesn't.
20160128 03:12:57< vultraz> exactly
20160128 03:13:22< shadowm> Why is the dialog so tall by default?
20160128 03:13:32< shadowm> And why can I select multiple items in Advanced?
20160128 03:13:39-!- iceiceice [~chris@50.245.222.235] has joined #wesnoth-dev
20160128 03:13:39-!- iceiceice [~chris@50.245.222.235] has quit [Changing host]
20160128 03:13:39-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160128 03:13:56< shadowm> And why are you using Title Case in some items?
20160128 03:13:57< vultraz> shadowm: because the advanced panel stretches it
20160128 03:14:27< vultraz> multiple items because it's not one toggle panel and there's no way currently to enforce only 1 selected node
20160128 03:15:03< iceiceice> fwiw in C++11 i have a new preferred way to do the MAKE_ENUM thing
20160128 03:15:16< shadowm> The GUI2 combobox needs the hover behavior implemented pronto.
20160128 03:15:17< iceiceice> where basically you use a C++11 enum class, but you use type traits to enable some "to_string" and "from_string" functions
20160128 03:15:27< iceiceice> that do the right things
20160128 03:15:44< iceiceice> the main thing about MAKE_ENUM in wesnoth is,
20160128 03:15:45< shadowm> *combobox dropdown menu
20160128 03:15:54< iceiceice> if it fails to parse a string it throws some kind of twml_exception thing that mordante invented
20160128 03:16:07< iceiceice> so you get a nice dialog box explaining that some enum in your wml was invalid
20160128 03:16:09-!- travis-ci [~travis-ci@ec2-54-145-162-202.compute-1.amazonaws.com] has joined #wesnoth-dev
20160128 03:16:10< travis-ci> wesnoth/wesnoth#8314 (master - b6d89ad : gfgtdf): The build failed.
20160128 03:16:10< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/105323352
20160128 03:16:10-!- travis-ci [~travis-ci@ec2-54-145-162-202.compute-1.amazonaws.com] has left #wesnoth-dev []
20160128 03:16:13< celticminstrel> "there's no way to enforce only 1 selected node" --> Is there no way to install a callback when a node is selected by the user?
20160128 03:16:33< iceiceice> but should be careful with it, if you use it in a place where that exception is not caught it may crash the program
20160128 03:16:42< celticminstrel> iceiceice: Wait, wait, what?
20160128 03:16:58< celticminstrel> What's this about to_string and from_string?
20160128 03:17:09< iceiceice> which part
20160128 03:17:19< celticminstrel> The C++11 stringable enums stuff.
20160128 03:17:19< iceiceice> are you asking about make_enum in wesnoth or the thing i use in another project
20160128 03:17:23< iceiceice> oh
20160128 03:17:38< vultraz> celticminstrel: ttreeview_node's fold/unfold functions are unimplemented 
20160128 03:17:50< celticminstrel> ???
20160128 03:18:12< iceiceice> celticminstrel, the way i do it is like,
20160128 03:18:15< iceiceice> first you make a traits like
20160128 03:18:38< iceiceice> namespace util { namespace traits { template <typename T> struct Get_Enum_String_Data {}; } }
20160128 03:18:38< shadowm> I kind of expected 'custom' advanced preferences entries to have a button or some other kind of indication that selecting them does stuff.
20160128 03:18:51< shadowm> For example, the dropdown menu glyph that comboboxes use.
20160128 03:19:12< iceiceice> then when you want to make an enum, you use like boost_pp_for_each, or one of the alternatives,
20160128 03:19:19< iceiceice> to make a variadic macro that can take allt he strings you want
20160128 03:19:25< iceiceice> so in mine it looks like this
20160128 03:19:40< iceiceice> ENUM_STRING(my_enum, first, second, third);
20160128 03:19:52< celticminstrel> Ah, okay, so it's not like there's some standard way of actually producing the strings.
20160128 03:20:08< iceiceice> no its a nonstandard thing
20160128 03:20:13< iceiceice> but its a lot less painful
20160128 03:20:21< iceiceice> and in c++11 you can also forward declare enums
20160128 03:20:25< celticminstrel> And still uses Boost.Preprocessor. Not that that's a bad thing.
20160128 03:20:30< iceiceice> actually my version doesn't use boost pp
20160128 03:20:46< shadowm> vultraz: You might want to consider maximum_height = 500.
20160128 03:20:48< iceiceice> theres a pretty lightweight alternative for many purposes
20160128 03:21:09< iceiceice> https://github.com/swansontec/map-macro
20160128 03:21:45< iceiceice> this one is not quite as powerful as the boost stuff, but its adequate for this at least
20160128 03:21:50< shadowm> vultraz: Also consider mvoing the Friends controls _above_ the acquaintainces list.
20160128 03:22:08< vultraz> shadowm: what for?
20160128 03:22:09< shadowm> To eliminate that issue where their position varies as the list gets filled up.
20160128 03:22:30< vultraz> is that a ux faux-pas
20160128 03:22:37< shadowm> Very.
20160128 03:23:22< shadowm> I like to call that the "teasing troll layout".
20160128 03:23:28< vultraz> including the text box?
20160128 03:23:48< shadowm> "Oh you want to click this button again? Well, too bad, I just shifted it a bit so you will click something else instead."
20160128 03:24:00< shadowm> Especially the textbox.
20160128 03:24:20< vultraz> OK
20160128 03:24:33< shadowm> The alternative, of course, would be that you managed to get the controls to stay put at the bottom regardless of the list's height.
20160128 03:24:43< shadowm> But then that'd look weird with a sufficiently short list.
20160128 03:25:07< vultraz> if I move them to the top, I should put the buttons on one line
20160128 03:25:34< vultraz> don't you think?
20160128 03:25:44< shadowm> The Remove button's placement is a bit questionable since it applies to the selection, but the text input.
20160128 03:25:59< shadowm> The way it is it looks like it applies to the selection instead.
20160128 03:26:25< shadowm> Alerts... I bet this will look funny in translations.
20160128 03:26:38< vultraz> I'mm probably go back to the dialog
20160128 03:26:40< vultraz> I'll*
20160128 03:26:44< shadowm> "Notificación de escritorio" > "Desktop notification"
20160128 03:26:56< shadowm> "Reproducir sonido" > "Play Sound (sic)"
20160128 03:27:08< shadowm> "También en lobby" > "Also in lobby"
20160128 03:27:43< shadowm> I may suggest lifting or increasing the maximum_width.
20160128 03:28:22< shadowm> Also, testing with translations (which probably won't work unless you use the wesnoth textdomain instead of wesnoth-lib for testing).
20160128 03:28:51< shadowm> My cache is really big.
20160128 03:29:02< shadowm> 269 MiB.
20160128 03:29:14< vultraz> P_P
20160128 03:29:16< vultraz> clean it
20160128 03:29:30< shadowm> No, I want to keep it that way for when I get to implement the autoclean option.
20160128 03:31:14< shadowm> Advanced really needs a lot of work on the widgets, still.
20160128 03:31:20< vultraz> Elaborate
20160128 03:31:24< shadowm> I already did.
20160128 03:31:41< shadowm> Oh, and Advanced Graphic Options should really be "Graphics scaling options" or something.
20160128 03:31:48< shadowm> At least for now.
20160128 03:32:32< shadowm> Maybe in a few years when it gets expanded with all kinds of confusing OpenGL options it can earn its curren title back.
20160128 03:33:41< shadowm> And change that dialog caption some day.
20160128 03:33:49< vultraz> shadowm: good? https://www.dropbox.com/s/7uemyrf75ehkf32/FLlayout.PNG?dl=0
20160128 03:34:02< shadowm> It wasn't ever intended to hit a public repository or PR Like that.
20160128 03:34:27< shadowm> 00:25:45 <shadowm> The Remove button's placement is a bit questionable since it applies to the selection, but the text input.
20160128 03:34:30< shadowm> 00:26:00 <shadowm> The way it is it looks like it applies to the selection instead.
20160128 03:34:40< shadowm> s/but/not/
20160128 03:34:45< celticminstrel> But when you add all kinds of confusing OpenGL options, you can make those separate advanced preferences!
20160128 03:35:02< shadowm> Maybe not.
20160128 03:35:25< vultraz> it also applies to the text input
20160128 03:35:32< shadowm> It doesn't.
20160128 03:35:40< vultraz> it does
20160128 03:35:54< shadowm> Oh, it does. Sometimes.
20160128 03:36:23< shadowm> In fact, the whole thing just entered full non-deterministic behavior mode.
20160128 03:36:42< vultraz> what do you recommend
20160128 03:36:51< shadowm> I typed an entry, tried remove, something else was removed. Then did it again, it reappeared along with two or three more entries.
20160128 03:37:02< vultraz> wait what
20160128 03:37:16< shadowm> I recommend more thorough testing.
20160128 03:37:27< vultraz> shadowm: it works perfectly for me :/
20160128 03:37:46< celticminstrel> What are we talking about here? Friends list?
20160128 03:38:30< vultraz> yes
20160128 03:38:40< shadowm> vultraz: Do this: type into the textbox an existing entry, remove it; type the exact same entry, remove it again; repeat this a few times, then type the exact same entry, click on add as a friend.
20160128 03:39:10< shadowm> Make sure you have a non-zero, preferably > 5 number of entries at the beginning of this procedure.
20160128 03:40:30< vultraz> Ok observed
20160128 03:47:01< vultraz> shadowm: out of curiosity, is this valid syntax? "void add_acquaintance(const std::string& nick, mode, notes)" I know you can do multiple assignment with variables, wondering if it worked with argument lists 
20160128 03:49:12< vultraz> seems not
20160128 03:50:16< shadowm> No, unless 'mode' and 'notes' name types (in which case they declare anonymous arguments).
20160128 03:53:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 03:55:15-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 240 seconds]
20160128 03:57:09< celticminstrel> Yeah, function arguments aren't quite the same as variable declarations.
20160128 03:57:30-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160128 03:57:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160128 04:04:43-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20160128 04:55:12-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160128 04:57:47-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Client Quit]
20160128 05:01:10-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 260 seconds]
20160128 05:19:44-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 256 seconds]
20160128 05:31:46-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has quit [Quit: "The highest possible stage in moral culture is when we recognize that we ought to control our thoughts." - Charles Darwin]
20160128 05:37:45-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has joined #wesnoth-dev
20160128 05:56:17-!- SigurdFD [~SigurdFD@dynamic-acs-72-23-109-141.zoominternet.net] has quit []
20160128 06:05:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 06:09:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160128 06:32:56-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20160128 06:33:25-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160128 06:47:41< Aginor> 'lo
20160128 06:50:04< vultraz> allos
20160128 06:50:37< Aginor> allo allo
20160128 06:52:28< Aginor> what's new under the sun?
20160128 06:54:13< vultraz> polishing my 50+ commit large PR
20160128 06:54:49< Aginor> oooh
20160128 06:54:51< Aginor> exciting
20160128 06:54:55< Aginor> gui2 stuff?
20160128 06:55:56< vultraz> yeah, the new pref dialog
20160128 06:56:01< vultraz> pr 581
20160128 06:56:01< Aginor> nice
20160128 06:57:08< vultraz> you?
20160128 06:57:21< Aginor> just kicking off an initial build
20160128 06:57:38< Aginor> going to try to make a few improvements to those redraw issues
20160128 06:57:50< vultraz> :D
20160128 07:00:53< vultraz> ah, std::find returns last if no member found 
20160128 07:00:57< vultraz> well this is annoying
20160128 07:03:14< Aginor> :D
20160128 07:04:06< vultraz> I'll circumvent this in a hacky way by rebuilding the whole list
20160128 07:04:41< Aginor> :/
20160128 07:05:25< vultraz> well, I can't use find because the appropriate entry may actually be the last one
20160128 07:05:54< vultraz> if I don't use find, the list has to be rebuilt anyway
20160128 07:10:31-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 245 seconds]
20160128 07:11:04< vultraz> shadowm: friends list issue should be fixed now
20160128 07:24:38< vultraz> shadowm: if I delete the setter widget pointers, wesnoth crashes - what does this mean 
20160128 07:26:29< shadowm> vultraz: ... What's the exact code?
20160128 07:27:17< shadowm> 04:05:25 <vultraz> well, I can't use find because the appropriate entry may actually be the last one
20160128 07:27:42< shadowm> Sigh don't tell me I'm going to have to explain iterators and STL containers for the tenth time.
20160128 07:28:12< shadowm> The appropriate entry is never the container's end iterator. The end iterator always points one past the last element.
20160128 07:28:30< vultraz> it said std::find returns .last() not .end()
20160128 07:28:41< shadowm> Because you gave it .last().
20160128 07:28:52< shadowm> (Whatever it is for whatever type.)
20160128 07:29:22< vultraz> uh
20160128 07:29:24< vultraz> "Returns an iterator to the first element in the range [first,last) that compares equal to val. If no such element is found, the function returns last."
20160128 07:29:50< shadowm> Yes, last is whatever you gave it.
20160128 07:30:04< shadowm> And that notation FYI means inclusive range to the left, exclusive to the right.
20160128 07:30:10< vultraz> Oh
20160128 07:30:23< shadowm> e.g. the set of integers described by [0, 3) is { 0, 1, 2 }, not { 0, 1, 2, 3 }.
20160128 07:30:30< vultraz> I thought it literally meant the last element
20160128 07:31:40< shadowm> The 'last' parameter in std::find and other generic algorithms is whatever you gave it. It doesn't necessarily have to be the end iterator of whichever container you're dealing with.
20160128 07:31:51< shadowm> You might not even be dealing with a container, in fact.
20160128 07:33:23< shadowm> For example, given `std::vector<int> foo = { 0, 1, 2, 3, 4 };`, you can search a _subset_ of the container like this:
20160128 07:34:17< shadowm> `auto first_odd_number = std::find(foo.begin(), foo.begin() + 2, [](int n) { return n % 2; });`
20160128 07:34:42< shadowm> That'll only search among the first two elements (0 and 1).
20160128 07:35:00< shadowm> (Yes I'm using C++11 here because I can't be bothered to type iterator type names.)
20160128 07:35:51< vultraz> what's []
20160128 07:36:53< shadowm> auto foo = [](int n) { return n % 2; };
20160128 07:36:55< shadowm> A lambda expression.
20160128 07:37:03< vultraz> as, as I thought
20160128 07:38:28-!- irker549 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160128 07:40:15< shadowm> In C++03 you'd write that whole thing like this: http://pastebin.com/akcKCumY
20160128 07:40:44< shadowm> And yes, I realize I have the logic inverted and first_odd_number actually should be called first_even_number.
20160128 07:41:52< vultraz> does C++11 seriously simplify stuff that much o_O
20160128 07:42:09< shadowm> No.
20160128 07:42:44< vultraz> anyway, I'll take a look at the commit again
20160128 07:42:56< shadowm> 04:26:29 <shadowm> vultraz: ... What's the exact code?
20160128 07:43:08< vultraz> the final solution might be best anyway
20160128 07:43:08< shadowm> What are you deleting? There are two options here and one of them is blatantly wrong.
20160128 07:43:27< vultraz> shadowm: um... the setter_widget pointer...
20160128 07:44:07< shadowm> NO. THAT'S THE BLATANTLY WRONG CHOICE.
20160128 07:44:23< shadowm> WHY WOULD YOU DELETE A POINTER YOU JUST TOLD YOUR CALLEE TO USE IN THE LONG TERM.
20160128 07:45:53< vultraz> I DON'T KNOW YOU'RE NOT MAKING THIS SIMPLE FORM E
20160128 07:45:55< vultraz> FOR*
20160128 07:45:57< vultraz> OK
20160128 07:45:58< shadowm> 23:34:18 <shadowm> It is possible that swap_child() transfers ownership of the old widget to the caller and ownership of the new widget to the callee.
20160128 07:46:03< shadowm> 23:36:14 <shadowm> The thing is that vultraz ignores the return value.
20160128 07:46:07< shadowm> 23:36:34 <shadowm> Iff swap_child is transferring ownership of the old widget to the caller, then that's still a leak source.
20160128 07:46:07< vultraz> AND HOW DO I KNOW THAT
20160128 07:46:09< vultraz> HOW HOW HOW
20160128 07:46:27< shadowm> 23:39:03 <vultraz> swap_grid returns the old widget
20160128 07:46:31< shadowm> 23:39:42 <shadowm> Yes, we know, the question is who owns it.
20160128 07:46:33< shadowm> 23:40:18 <shadowm> As I said, the normal assumption is that you get to own it (read: destroy it).
20160128 07:46:41< shadowm> Clear enough now?
20160128 07:47:14< shadowm> Notice that you arrived to half of the conclusion by yourself.
20160128 07:47:31< shadowm> But then decided to ignore that epiphany for some reason, shooting yourself in the foot in the process.
20160128 07:48:30< vultraz> gfgtdf: src\scripting\lua_gui2.cpp|649|error: 'class gui2::tcontrol' has no member named 'set_dirty'|
20160128 07:48:37< vultraz> shadowm: ok ok ok
20160128 07:48:40< vultraz> so are you saying
20160128 07:48:48< vultraz> I need to... delete what's returned
20160128 07:49:18< shadowm> Yes, that's the only possible reading of that discussion.
20160128 07:49:48< shadowm> And note that no-one has confirmed yet whether you are allowed to do that either, although it's a sane assumption.
20160128 07:51:35< shadowm> Also, to make this clear, I don't want to make this simple for you. You need to learn C++ and you won't learn much if I give you the code every time.
20160128 07:51:50< vultraz> But I ignore the return value
20160128 07:51:58< vultraz> Is that the problem here?
20160128 07:52:21< shadowm> If you ignore the return value, what do you think happens to it?
20160128 07:52:41< vultraz> I don't know... but I guess it... hangs around?
20160128 07:52:47< shadowm> It's a plain pointer.
20160128 07:53:03< shadowm> If no-one notes its value and then releases the memory it points to...
20160128 07:53:08< shadowm> What do you think will happen?
20160128 07:53:36< vultraz> Well I assume the correct answer is memory leak
20160128 07:53:41< shadowm> It's like an integer variable. It does nothing by itself but exist for a limited amount of time.
20160128 07:53:54< vultraz> gfgtdf: nvm I found the right function
20160128 07:54:53< shadowm> The pointer exists, the pointer ceases to exist, but what it pointed to keeps on existing unless made to disappear by force.
20160128 07:55:29< vultraz> So in this case, the old widget?
20160128 07:55:53< shadowm> 04:46:27 <shadowm> 23:39:03 <vultraz> swap_grid returns the old widget
20160128 08:00:59-!- molgrum [~molgrum@unaffiliated/molgrum] has quit [Ping timeout: 276 seconds]
20160128 08:07:14< vultraz> delete details_grid->swap_child("setter", setter_widget, true);
20160128 08:07:18< vultraz> works 
20160128 08:07:48< shadowm> Well, at least that suggests (but doesn't confirm) that the old widget's ownership is transferred to the caller.
20160128 08:08:44< shadowm> ... You know, I'm apalled that it didn't occur to any of us to grep for previous use-cases.
20160128 08:08:54< shadowm>         widget = parent_grid->swap_child(id, widget, false);
20160128 08:09:00< shadowm>         delete widget;
20160128 08:09:14< shadowm> swap_grid() (tmulti_page implementation detail)
20160128 08:09:44< shadowm> Ditto in the identically-named function that's a tstacked_widget implementation detail.
20160128 08:10:14< shadowm> Ditto for tlistbox.
20160128 08:11:00< shadowm> Ditto for twindow.
20160128 08:12:03< vultraz> I have been grepping
20160128 08:12:11< shadowm> I'm glad to see there's still some sanity left in GUI2.
20160128 08:13:11< shadowm> (Also, all those instances have an assertion check for a null pointer for some reason. `delete <null pointer>` has a well-defined behavior, which is to do nothing at all.)
20160128 08:14:58< shadowm> (... That means you don't need to check for that case, in case that wasn't clear.)
20160128 08:15:31< vultraz> That was clear
20160128 08:15:55< vultraz> I may be dumb in areas I don't understand but something as basic as that I do understand 
20160128 08:31:08< vultraz> gfgtdf: c402d4cc7eb5  fixed the toggle button-as-tree view-toggle crash, ty 
20160128 08:32:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 08:32:50-!- irker371 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160128 08:32:50< irker371> wesnoth: Charles Dang wesnoth:master 6a636dcd1c4a / src/scripting/lua_gui2.cpp: Fixup b6d89addd36d https://github.com/wesnoth/wesnoth/commit/6a636dcd1c4a9031aec94f96e0c4b4b8d8939808
20160128 08:36:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160128 08:40:40< vultraz> god, rebasing my branch is such a PAIN
20160128 08:40:42< vultraz> so many commits
20160128 08:56:53< vultraz> shadowm: would you object to adding alignment functionality to the default label definition? It seems silly that there's a separate definition just so you can enable alignment 
20160128 09:15:37-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160128 09:32:38-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 276 seconds]
20160128 09:34:23-!- molgrum [~molgrum@h-94-103.a230.priv.bahnhof.se] has joined #wesnoth-dev
20160128 09:34:24-!- molgrum [~molgrum@h-94-103.a230.priv.bahnhof.se] has quit [Changing host]
20160128 09:34:24-!- molgrum [~molgrum@unaffiliated/molgrum] has joined #wesnoth-dev
20160128 09:50:55-!- travis-ci [~travis-ci@ec2-54-163-179-47.compute-1.amazonaws.com] has joined #wesnoth-dev
20160128 09:50:56< travis-ci> wesnoth/wesnoth#8320 (master - 6a636dc : Charles Dang): The build was fixed.
20160128 09:50:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/105362621
20160128 09:50:56-!- travis-ci [~travis-ci@ec2-54-163-179-47.compute-1.amazonaws.com] has left #wesnoth-dev []
20160128 09:52:56-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160128 09:55:08-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 256 seconds]
20160128 09:55:09-!- wedge010 is now known as wedge009
20160128 10:15:16< Aginor> vultraz: I've made progress in the right direction, but it's not done yet. I have a (broken) skeleton implementation of layered drawing
20160128 10:26:27< vultraz> Aginor: layered drawing, you say?
20160128 10:26:31< vultraz> Aginor: what does this mean?
20160128 11:00:16-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160128 11:10:18-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160128 11:14:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 11:14:33 * zookeeper wonders what's up with caching of ToD-colored images
20160128 11:14:40-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Ping timeout: 250 seconds]
20160128 11:19:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160128 11:20:00-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160128 11:22:50-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20160128 11:33:00-!- irker371 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160128 11:53:44-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160128 12:10:35-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160128 12:27:56-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160128 12:42:06-!- prkc [~prkc@54001BD3.dsl.pool.telekom.hu] has joined #wesnoth-dev
20160128 12:44:02-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160128 12:54:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 13:21:11-!- Kwandulin [~Miranda@p200300760F6924148D7326ADE1864CA8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160128 13:46:59-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20160128 13:58:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160128 14:00:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 14:26:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160128 14:26:35-!- gfgtdf [~chatzilla@f054154023.adsl.alicedsl.de] has joined #wesnoth-dev
20160128 14:27:59< gfgtdf> shadowm: is there a reason for the "add-ons" part in the ~add-ons/<addonname> syntax? i mean is ~ ever followed by something else than add-ons ?
20160128 14:28:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 14:30:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160128 14:30:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 14:39:57< vultraz> gfgtdf: do you think it's possible to make tree views only have 1 node open at a time?
20160128 14:40:24< vultraz> gfgtdf: also thank you for your fixes earlier 
20160128 14:40:40< gfgtdf> vultraz: you mena without changes to the treeview class ?
20160128 14:41:06< vultraz> gfgtdf: possibly but it's not necessary 
20160128 14:42:36< gfgtdf> vultraz: hmm not sure, afaik with the current code is only possible to fold/unfold noded black clicking on then not via a c++ api
20160128 14:42:55< vultraz> ya.. ttree_view_node::fold is unimplemented 
20160128 14:43:11< vultraz> I tried implementing it a few days ago but I failed miserably :P
20160128 14:43:14< gfgtdf> vultraz: but i do think it shoudlnt t hard to implement, you just have t copy from the unckick function 
20160128 14:43:30< gfgtdf> onclick
20160128 14:43:41< vultraz> what about the recursive argument?
20160128 14:43:55< gfgtdf> vultraz: hmm i'D ignore that for now
20160128 14:44:26< gfgtdf> vultraz: so that only the current node is (un)folded
20160128 14:44:39< gfgtdf> vultraz: ignore it if you dont need it
20160128 14:44:41< gfgtdf> i mean
20160128 14:50:08-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160128 14:53:51-!- mjs-de [~mjs-de@x4db52ce1.dyn.telefonica.de] has joined #wesnoth-dev
20160128 14:57:47-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160128 15:06:10< gfgtdf> shadowm: i also wonder why [binary_path] epxected a differnt format? binary path rxpectes data/add-ons/ instead of the normal ~add-ons/
20160128 15:08:49< vultraz> gfgtdf: hm.. is there one ttreeview_node object for each node?
20160128 15:08:53< vultraz> in a tree*
20160128 15:09:08< gfgtdf> vultraz: yes
20160128 15:09:43< vultraz> ok
20160128 15:10:32< vultraz> so i can bind an event to that node
20160128 15:13:18< vultraz> but
20160128 15:13:20< vultraz> uh...
20160128 15:13:26< vultraz> hm
20160128 15:13:40< vultraz> idk im thinking like there should be an index of nodes
20160128 15:14:21< vultraz> or maybe i can bind a function to each node and then somehow get the 'last node clicked'
20160128 15:21:05< vultraz> hm
20160128 15:21:25< vultraz> maybe i didn't need to add event handling to the nodes
20160128 15:27:10< vultraz> there's already a selection change handler in the main class
20160128 15:27:43< gfgtdf> vultraz: you need a list of ttreeview_node* in your preferenced dialog, then in teh togglebutton state callback for the treview togglebuttons, you set all other noded from that list fo folded
20160128 15:28:14< gfgtdf> vultraz: treeviews are made to have 2 tooglepanels/buttons: oine for teh 'expansion' and oen for the 'selection'
20160128 15:29:22< gfgtdf> vultraz: think of it as the treeview in file exploreres, where anyy folder cna be 'expanded' but there is onyl one folder 'seected (shown on teh rogth side panel)'
20160128 15:29:45< gfgtdf> vultraz: we currently coplateley ignore the 'selceted' part of the reeeview widget
20160128 15:30:52< vultraz> gfgtdf: I committed this as part of my PR but now I don't think I actually need it https://github.com/Vultraz/wesnoth/commit/1da994d6171ca2234c5caa166edf2ed46c2f4dd9
20160128 15:38:27-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160128 15:39:46-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20160128 15:57:57< gfgtdf> vultraz: if you dont need it you can still remvoe it
20160128 16:02:24-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 250 seconds]
20160128 16:17:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 16:17:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160128 16:18:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 16:19:54-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160128 16:28:55-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160128 16:30:34-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds]
20160128 16:38:15-!- Kwandulin [~Miranda@p200300760F6924148D7326ADE1864CA8.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20160128 16:39:03-!- Kwandulin [~Miranda@p200300760F6924148D7326ADE1864CA8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160128 16:46:23-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds]
20160128 16:54:55-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160128 16:54:55-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160128 17:20:09-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160128 17:28:45-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 17:32:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160128 17:36:00-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds]
20160128 17:44:16-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160128 17:44:22-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160128 18:35:49-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160128 18:48:59-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160128 18:55:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 18:55:40< zookeeper> what's with the constant printer support number spam...
20160128 18:55:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160128 18:55:54-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 19:04:00< gfgtdf> shadowm: wiki gets spammed again
20160128 19:06:39< gfgtdf> shadowm: starting today 09:24
20160128 19:07:35< zookeeper> urgh, same crap there
20160128 19:13:15< zookeeper> given the volume, he might want to just rollback the whole thing instead of having someone start blocking them individually
20160128 19:14:28< zookeeper> curiously, all of the spam account names are pretty random, but one of them is named "Asheviere" O.o
20160128 19:14:35-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20160128 19:15:59< zookeeper> but sadly looks like the registrations just need to be disabled.
20160128 19:22:58-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160128 19:23:05-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160128 19:28:18-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 250 seconds]
20160128 19:37:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160128 20:18:58< gfgtdf> shadowm: maybe you can have a look at https://github.com/wesnoth/wesnoth/pull/584 ?
20160128 20:24:09-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160128 20:43:53-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20160128 20:52:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 20:52:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 20:57:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160128 21:02:44-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160128 21:02:45-!- Kwandulin [~Miranda@p200300760F6924148D7326ADE1864CA8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160128 21:04:20< ancestral> There are still many languages missing of the logo
20160128 21:04:34< ancestral> Surprisingly, I don’t see German
20160128 21:05:05< ancestral> images/misc/I10n/
20160128 21:06:43-!- mx6523 [~mx6523@104-137-14-252.res.bhn.net] has joined #wesnoth-dev
20160128 21:09:30-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has joined #wesnoth-dev
20160128 21:11:28-!- travis-ci [~travis-ci@ec2-54-145-162-202.compute-1.amazonaws.com] has joined #wesnoth-dev
20160128 21:11:29< travis-ci> gfgtdf/wesnoth-old#592 (filesystem_changes - 2ef4ebb : gfgtdf): The build has errored.
20160128 21:11:29< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/105509628
20160128 21:11:29-!- travis-ci [~travis-ci@ec2-54-145-162-202.compute-1.amazonaws.com] has left #wesnoth-dev []
20160128 21:14:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160128 21:15:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 21:15:41< bumbadadabum> ok I know I'm appearing out of nowhere but is anyone here going to FOSDEM?
20160128 21:17:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160128 21:19:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160128 21:19:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 21:21:05< ancestral> Interesting
20160128 21:21:08< ancestral> http://www.wesnoth.org/gettext/index.php?version=trunk&package=alloff
20160128 21:21:19< ancestral> I wonder what the 1 untranslated English string is
20160128 21:25:56-!- travis-ci [~travis-ci@ec2-54-163-179-47.compute-1.amazonaws.com] has joined #wesnoth-dev
20160128 21:25:57< travis-ci> gfgtdf/wesnoth-old#593 (filesystem_changes - 2129fd7 : gfgtdf): The build failed.
20160128 21:25:57< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/105522908
20160128 21:25:57-!- travis-ci [~travis-ci@ec2-54-163-179-47.compute-1.amazonaws.com] has left #wesnoth-dev []
20160128 21:40:39< shadowm> ......................
20160128 21:41:47< gfgtdf> shadowm: ?
20160128 21:42:22< shadowm> They are editing the wiki like every minute or something, holy crap.
20160128 21:42:44< ancestral> “I SEE YOU”
20160128 21:43:18< gfgtdf> shadowm: y its the same as yesterday.
20160128 21:43:34< ancestral> yuck, that’s a crappy recent history
20160128 21:43:38< shadowm> No wonder RecentChanges becomes useless.
20160128 21:44:18< gfgtdf> shadowm: you can set teh entry limit to 5000 :)
20160128 21:44:49< shadowm> Really? When I tried 1000 it looked the same as 500 so I just assumed it didn't accept arbitrary values.
20160128 21:45:28< gfgtdf> shadowm: hmm 1000 works for me too
20160128 21:45:30< shadowm> Okay that's a lot of spam.
20160128 21:45:33< ancestral> There’s also x number of days
20160128 21:45:49< shadowm> So it starts around 06:24 <some time zone>.
20160128 21:45:55< gfgtdf> working as in 'shows 1000 entries'
20160128 21:45:56< shadowm> Oh, it's my time zone.
20160128 21:46:23< shadowm> It's worth noting that this is the same spam that's been hitting the forums as of late.
20160128 21:46:51< shadowm> So they cracked the new captcha questionnaire in a matter of hours, how odd.
20160128 21:47:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160128 21:48:03< ancestral> Just curious
20160128 21:48:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 21:48:20< ancestral> How many legit accounts do you think people are creating on the wiki in a month?
20160128 21:48:45< shadowm> Probably less than 5.
20160128 21:49:01< ancestral> And how many of those do you think already have an account on the forums?
20160128 21:49:02< shadowm> So I still have RecentChanges open with days=30 limit=5000...
20160128 21:49:27< shadowm> I don't see changes made by anyone registered this month before the spam starts today.
20160128 21:50:50< shadowm> I'm just going to throw in the towel and tell people to ask zookeeper and vultraz for assistance with creating accounts from now on.
20160128 21:50:53< ancestral> Maybe it’d be easier to just have people request access to the wiki (via PM or what-have-you) than to fight spam from bad accounts
20160128 21:50:57< ancestral> Yeah
20160128 21:52:40-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 260 seconds]
20160128 21:52:46< shadowm> Okay, the wiki is back to this (UTC) with non-admin registrations disabled:
20160128 21:52:47< shadowm> -rw------- 1 root root 148176938 Jan 28 05:31 wiki.mysqldump.1.gz
20160128 21:52:55-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160128 21:53:15< shadowm> There were no changes since then before the spam begins (.
20160128 21:54:10 * zookeeper approves
20160128 21:54:56< zookeeper> so what do i need to do when someone tells me they want to create an account? i have no idea whatsoever.
20160128 21:55:31-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160128 21:56:35-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20160128 21:56:36-!- wedge010 is now known as wedge009
20160128 22:02:11< shadowm> zookeeper, vultraz: https://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_account_creation   Second note.
20160128 22:02:26< zookeeper> great, thanks
20160128 22:03:02< gfgtdf> shadowm: you know how i could CURRENT_FILE returns teh name of the file that used a macro instead of teh file that defines a macro in https://github.com/wesnoth/wesnoth/pull/584?
20160128 22:03:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160128 22:03:16< shadowm> I'm wondering exactly how to approach the messaging issue.
20160128 22:03:38< shadowm> I could create yet another forum group for wiki admins.
20160128 22:04:32< nurupo> shadowm: can't you just make wiki accounts read-only and require administrator to approve them, since there are less than 5 legit accounts created per month?
20160128 22:04:50< shadowm> I could install the extension cited in that page and then suffer next time I want to ugprade the wiki and it turns out one of the extensions hasn't been updated yet.
20160128 22:05:00< shadowm> Like I'm doing right now with the forums behind the scenes.
20160128 22:05:25< shadowm> nurupo: I think you are lagging about 20 minutes behind.
20160128 22:05:46< nurupo> yeah, haven't read all of the backlog
20160128 22:06:55< nurupo> that's what we do with https://wiki.tox.chat/
20160128 22:06:56-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160128 22:07:15< shadowm> gfgtdf: 11:27:59 <gfgtdf> shadowm: is there a reason for the "add-ons" part in the ~add-ons/<addonname> syntax? i mean is ~ ever followed by something else than add-ons ?
20160128 22:07:32-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: ancestral]
20160128 22:07:36< shadowm> Theoretically, yes, it can be.
20160128 22:08:25< shadowm> The tilde prefix selects <user data>/data as opposed to <game data>/data. Theoretically we could have more directories in the former than just 'add-ons', and in fact it was my plan back in 1.5.x before I decided to drop it.
20160128 22:08:36-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160128 22:08:57< shadowm> 1.7.x, not 1.5.x.
20160128 22:09:13< gfgtdf> shadowm: what else for example had you in mind ?
20160128 22:09:13< shadowm> When I renamed <user data>/data/campaigns to <user data>/data/add-ons.
20160128 22:09:41< shadowm> Originally, all add-ons where in 'campaigns', so the alternative I considered was having one directory for each type of add-on. 
20160128 22:10:10< shadowm> But I thought this would confuse and inconvenience people more than help them, and it wasn't going to make the C++ any simpler either.
20160128 22:11:01< shadowm> So I think this is one thing we want to keep around for future-proofing in case someone later decides they want a <user data>/data/cores or something .
20160128 22:11:34< shadowm> Also, I think Wesnoth used to try to load <user data>/data/units by default back then? Not sure, though.
20160128 22:13:08< shadowm> And conversely, someone might want to ship a custom version of Wesnoth where there is a <game data>/data/add-ons directory.
20160128 22:13:40< shadowm> 12:06:11 <gfgtdf> shadowm: i also wonder why [binary_path] epxected a differnt format? binary path rxpectes data/add-ons/ instead of the normal ~add-ons/
20160128 22:14:17< shadowm> IIRC it's because the code implementing binary paths is a bit special and behaves like the old @ preprocessor path prefix used to do.
20160128 22:14:48< gfgtdf> shadowmwhat is teh @ prefix ?
20160128 22:15:05< shadowm> `{@campaigns/Foo_Bar}` was equivalent to a non-failing `{campaigns/Foo_Bar} {~campaigns/Foo_Bar}`, loading both the game data and user data versions of the given path.
20160128 22:15:32< gfgtdf> shadowm: hm ok
20160128 22:15:34< shadowm> Binary paths are implemented in such a way that Wesnoth will try every possible prefix until it finds the file it wants and gives up.
20160128 22:16:18< shadowm> So when you have image=foobar.png, Wesnoth tries <binary path 1>/images/foobar.png, <binary path 2>/images/foobar.png, and so on, in LIFO order I think.
20160128 22:17:08< gfgtdf> shadowm: i dotn think thats a good way: if [binary_path] data/add-ons aloc makes the engne loook at exe_dir/data/add-ons this wouldnt really increas ethe changes of loading a file
20160128 22:17:44< gfgtdf> finding*
20160128 22:17:45< shadowm> And each <binary path> is assumed to be both in user data and game data.
20160128 22:18:45< gfgtdf> shadowm: i think taht should be changes so that binary_path uses the same syntax as ~add-ons so that then it will onyl look at userdata for that.
20160128 22:18:45< shadowm> And why the leading data/ component? Well, there is an implicit binary path that doesn't have it.
20160128 22:19:05< shadowm> All our GUI infrastructure relies on that binary path existing.
20160128 22:19:47< shadowm> e.g. <game data>/images and <game data>/sounds has resources used by GUI1 and GUI2, not expected to be used by (non-core) WML.
20160128 22:20:19< shadowm> That distinction was introduced in Wesnoth 1.3.x and IIRC was created specifically so _someone_ could make wmlscope's code simpler.
20160128 22:21:23< shadowm> Before then, <game data>/data/core/images, <game data>/data/core/sounds etc. didn't exist and everything just lived in <game data>/images and so on.
20160128 22:22:57< shadowm> So yeah, in a nutshell, binary_path is a bit more lower level and special than the preprocessor's (now also Lua's) path resolution.
20160128 22:23:17-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160128 22:28:34< gfgtdf> shadowm: but 'not intended' doesnt really guarantee anythign i assume. And it sureley not impossible that people find cases to use images like this: https://github.com/wesnoth/wesnoth/blob/master/images/help/closed_section.png in theor addon.
20160128 22:29:44< shadowm> The person in question liked to think they could policy everything using wmlscope.
20160128 22:31:01-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has quit [Quit: Leaving]
20160128 22:31:02< shadowm> I eventually got tired to arguing about it so I decided to start ignoring wmlscope's existence and just move on and pretend the file hierarchy distinction exists to make developers happy.
20160128 22:31:20< shadowm> *tired of
20160128 22:32:36-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds]
20160128 22:38:49-!- neverEnough [~nEnough@host58-11-dynamic.16-79-r.retail.telecomitalia.it] has joined #wesnoth-dev
20160128 22:41:05< shadowm> (I'm still thinking about your WML __FILE__-equivalent question.)
20160128 22:56:17< shadowm> vultraz: No, I wouldn't object if you can figure out how to do it in a clean fashion.
20160128 22:56:51< shadowm> Like [label] align = left/center/right/justify or something.
20160128 22:57:45-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160128 22:58:12< gfgtdf> shadowm: im still not complateley sure how it should behave if a file was included from a macro (afaik c++ doesn't tallow this case).
20160128 22:59:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160128 22:59:20< shadowm> It should be the path of the included file I'd say.
20160128 23:01:26< gfgtdf> shadowm: but do you intend to cleanup the preprocessor fiel and to remove these strange 'new' calls ?
20160128 23:02:18< gfgtdf> shadowm: why do we need this 'new' calls in teh first place. do we otherside risk a stackoverflow ?
20160128 23:02:28< shadowm> Nooooot really. silene wrote and rewrote the preprocessor with performance in mind, hence the unwieldy code. It's quite beyond my league, I'm afraid.
20160128 23:10:05< zookeeper> unrelated: as i mentioned, i did manage to make the terrain image preloading happen in a separate thread, and basically it seems to work exactly right. i just didn't attempt to put in any thread safety measures so i think it's rather volatile :>
20160128 23:10:30< zookeeper> +yet
20160128 23:11:24-!- Appleman1234 [~Appleman1@KD119104016226.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20160128 23:16:23< zookeeper> i was also delighted to learn that shoving something to a separate thread in a quick and dirty manner can handily be done as a one-liner.
20160128 23:21:54-!- mjs-de [~mjs-de@x4db52ce1.dyn.telefonica.de] has quit [Quit: On the road again]
20160128 23:24:59-!- Appleman1234 [~Appleman1@KD119104002166.au-net.ne.jp] has joined #wesnoth-dev
20160128 23:25:45< celticminstrel> Using boost::thread?
20160128 23:27:26-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20160128 23:36:47< ancestral> vultraz: If you change the language to Polish in the game, do you notice the logo updating?
20160128 23:37:09< ancestral> Also, Norwegian
20160128 23:38:08< gfgtdf> shadowm: you know how to fix teh __FILE__ issue ?
20160128 23:40:58< gfgtdf> shadowm: othesie i'd add  a 'is_file' parameter to those constructors to track whether  we are currenty in a macro or a file,. but i thought maybe you know a way without adding an extra variable.
20160128 23:45:17< shadowm> preprocessor_file is only ever used for files AFAIK.
20160128 23:46:41< shadowm> But I guess the problem is determining what created the preprocessor_data.
20160128 23:48:42-!- gfgtdf [~chatzilla@f054154023.adsl.alicedsl.de] has quit [Ping timeout: 256 seconds]
20160128 23:48:58< shadowm> I think the additional parameter is the best solution right now, really.
20160128 23:49:13< shadowm> Possibly the only one.
20160128 23:59:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160128 23:59:40-!- aidanhs [~aidanhs@81.4.110.234] has quit [Ping timeout: 245 seconds]
--- Log closed Fri Jan 29 00:00:06 2016