--- Log opened Sun Feb 07 00:00:53 2016
20160207 00:03:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160207 00:10:46-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160207 00:13:28-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Client Quit]
20160207 00:15:55< gfgtdf> zookeeper: did you use pr #587 to build with msvc ?
20160207 00:19:19< zookeeper> gfgtdf, no, i added them myself, and then followed http://www.setoreaustralia.com/msb8027-two-or-more-files-with-the-name-of-texture-cpp-will-produce-outputs-to-the-same-location/
20160207 00:19:48< gfgtdf> zookeeper: you think we should merge that pr still?
20160207 00:19:59-!- celmin [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160207 00:19:59-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Disconnected by services]
20160207 00:20:04-!- celmin is now known as celticminstrel
20160207 00:20:42< zookeeper> gfgtdf, i have no idea. i mean obviously the projectfiles need to be updated, but i can't tell anything by looking at the diff.
20160207 00:21:31< gfgtdf> zookeeper: hmm ok i'll just merge and hope for teh best then
20160207 00:21:55-!- irker047 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160207 00:21:55< irker047> wesnoth: Wedge009 wesnoth:master 4d26cf909ee3 / projectfiles/VC9/wesnoth.vcproj: vcproj: Add missing combobox and drop_down_list files. https://github.com/wesnoth/wesnoth/commit/4d26cf909ee39732d5e34fff08ca39b8ea2c13ec
20160207 00:21:55< irker047> wesnoth: gfgtdf wesnoth:master a32371f40bb6 / projectfiles/VC9/wesnoth.vcproj: Merge pull request #587 from Wedge009/vcproj_update https://github.com/wesnoth/wesnoth/commit/a32371f40bb6911eb078050e1758d2d6c20fe14b
20160207 00:22:05< gfgtdf> zookeeper: i think he did also do projectfile updates before
20160207 00:26:05< Aginor> yes, he's quite onto it
20160207 00:28:50-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has quit [Ping timeout: 240 seconds]
20160207 00:29:21-!- mjs-de [~mjs-de@77.181.67.198] has quit [Remote host closed the connection]
20160207 00:55:46-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds]
20160207 01:09:11-!- gfgtdf [~chatzilla@f054141091.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
20160207 02:11:23< vultraz> i can't understand why this code doesn't work :|
20160207 02:15:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160207 02:17:25< vultraz> huh
20160207 02:19:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 245 seconds]
20160207 02:19:59< vultraz> stderr seems to indicate the values are right
20160207 02:20:11< vultraz> but the actual button doesn't want to be set
20160207 02:22:06< vultraz> and it seems to mostly happen on the first button in the group
20160207 02:22:28< vultraz> AH
20160207 02:22:31< vultraz> I think I got it
20160207 02:22:37< vultraz> set the button, not this
20160207 02:23:40< vultraz> yes, now it seems to be working
20160207 02:23:43< vultraz> yay!
20160207 02:54:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160207 02:57:40-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160207 03:15:16< vultraz> celticminstrel: final effort https://github.com/Vultraz/wesnoth/commit/face5d1596798a71185c3d46d87f684b4dd33610
20160207 03:15:25< celticminstrel> Wow, your timing is amazing.
20160207 03:15:31< celticminstrel> I just got back.
20160207 03:15:33< vultraz> o_O
20160207 03:15:43< vultraz> *is telepathic, obvious*
20160207 03:15:51< celticminstrel> :P
20160207 03:16:20< vultraz> (oh, and ignore the TODO: add error comments, I just pushed a small fixup)
20160207 03:16:35< celticminstrel> Heh, the commit has begins with "face".
20160207 03:16:41< celticminstrel> ^hash
20160207 03:17:55< celticminstrel> BTW, are set_retval and set_value overridden from twidget or unique to ttoggle_button?
20160207 03:18:38< celticminstrel> Ugh, asserts. I hate those.
20160207 03:18:50< vultraz> according to the header... former is unique, latter is inherited from tselectable_
20160207 03:18:59< celticminstrel> If you must use them though, I suggest using the idiom that gives a decent error message.
20160207 03:19:13< vultraz> there's such a thing?
20160207 03:19:20< celticminstrel> Yup.
20160207 03:19:25< celticminstrel> It's a hack, but:
20160207 03:19:39< celticminstrel> assert(condition_which_must_be_true && "My error message");
20160207 03:20:31< celticminstrel> When an assert triggers, the entire contents of the parentheses is printed out as the error message, so you'll see the condition as the error message normally. So you only need to do that when the condition isn't self-explanatory.
20160207 03:21:44< celticminstrel> Anyway, getting back to it.
20160207 03:22:15-!- irker047 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160207 03:22:16< celticminstrel> Yay forward declarations.
20160207 03:24:46< celticminstrel> Well, the only thing that seems weird about it is that, despite all your claims of trying to make it generic, you modified the ttoggle_button class.
20160207 03:25:26< celticminstrel> Hmm, I guess it's unavoidable for execute_group_actions to be defined there, at least...
20160207 03:25:58< celticminstrel> Still, it's not an issue that you've done this, really.
20160207 03:26:08< celticminstrel> Oh, line 224 of ttoggle_button.cpp
20160207 03:26:53< celticminstrel> Did you put that static_cast in because it didn't compile without it, or because I told you to?
20160207 03:27:19< celticminstrel> Actually, I think the logic there is wrong.
20160207 03:27:31 * celticminstrel poke vultraz 
20160207 03:27:56< celticminstrel> Could you please describe, in English, what exactly that function is supposed to do.
20160207 03:30:49< vultraz> celticminstrel: calling set_value didn't work - the button's state would not change most of the time
20160207 03:30:57< vultraz> calling the argument button works perfectly
20160207 03:31:08< vultraz> but it needs to be cast as a ttoggle_button object
20160207 03:31:44< celticminstrel> Uhh.
20160207 03:31:48< vultraz> (that is, calling set_value on 'this' doesn't work, but calling it on the argument does)
20160207 03:31:57< celticminstrel> First of all, that cast is theoretically unsafe.
20160207 03:33:28< celticminstrel> So, "this" is the button that was clicked, correct?
20160207 03:33:47< vultraz> as far as i thought, yes
20160207 03:33:59< celticminstrel> set_retval is called for the clicked button, right?
20160207 03:34:06< vultraz> eh?
20160207 03:34:17< celticminstrel> set_retval is the entry point for this whole thing.
20160207 03:34:28< vultraz> it is?
20160207 03:34:39< celticminstrel> Yes, because that's where you call execute_group_actions.
20160207 03:34:57< vultraz> ...no?
20160207 03:35:02< vultraz> it was never in set_retval
20160207 03:35:08< vultraz> it was in set_value, but I moved it to signal_handler_left_button_click
20160207 03:35:12< vultraz> see the explanatory comment
20160207 03:35:38< celticminstrel> Oh, sorry, I got confused by the git diff happening to have set_retval's header right at the end of a hunk.
20160207 03:35:50< celticminstrel> Okay, so yes, at the entry point, "this" is the button that was clicked.
20160207 03:36:10< celticminstrel> So the bound widget in the function is the button that was clicked.
20160207 03:36:18< celticminstrel> Then the passed widget is... every other button.
20160207 03:36:35< celticminstrel> Hmm, yes, okay. Now that I think about it, your logic is indeed correct.
20160207 03:36:40< celticminstrel> However, it's still unsafe.
20160207 03:37:12< celticminstrel> If anyone every adds something other than a toggle button to a group, the game will call set_value on... I assume a NULL pointer.
20160207 03:37:41< vultraz> o_O
20160207 03:37:44< celticminstrel> Or worse, a pointer to some other widget that the runtime mistakenly thinks is actually a pointer to a toggle button.
20160207 03:37:49< vultraz> that doesn't sound good
20160207 03:38:01< celticminstrel> I don't know if static_cast returns NULL when the cast is incompatible.
20160207 03:38:16< celticminstrel> I wouldn't be surprised if it just returns the same pointer with a different type.
20160207 03:38:42< celticminstrel> I think what you need to change, then, is line 219. Swap the order of "this" and "_1".
20160207 03:38:50< celticminstrel> And then put 224 back how it was.
20160207 03:39:02< celticminstrel> I think that should get the same effect without the danger.
20160207 03:39:24< celticminstrel> Hmm.
20160207 03:39:33< celticminstrel> Am I wrong? I might be wrong.
20160207 03:40:06< celticminstrel> Right now, the code callse group_operator() N times on the same button with each successive button as the parameter.
20160207 03:40:27< celticminstrel> If you swap like I proposed, then it calls group_operator() once on each button with the clicked button as the parameter.
20160207 03:41:29< vultraz> oh?
20160207 03:41:35< celticminstrel> (Which I think somehow makes more sense but probably ends up coming out exactly the same in the end.)
20160207 03:41:36< vultraz> will try that
20160207 03:41:54< celticminstrel> But... does that eliminate the danger? It might not...
20160207 03:42:33< celticminstrel> Suppose we have a toggle button B, and a different sort of widget W.
20160207 03:43:09< celticminstrel> In the current setup, if the user clicks B, then the game first sets B's value to true, then tries to cast W to a toggle button so that it can set its value to false.
20160207 03:44:04< celticminstrel> In the swapped setup, if the user clicks B, there shouldn't be any problem - first B.group_operator is called, setting its own value to true, and then W.group_operator is called, which does its own thing.
20160207 03:44:39< celticminstrel> But then if the user clicks W, then B.group_operator..... ah yes, I see, the reason it's safer this way is that it's calling set_value on itself, rather than the argument.
20160207 03:44:48< celticminstrel> Okay, yeah, I'm pretty sure I'm not wrong. >_>
20160207 03:44:54< celticminstrel> Let me know how it goes.3
20160207 03:45:52< celticminstrel> BTW, line 224 was also where I suggested changing the condition to (static_cast<twidget*>(this) == button), if you're worried about pointer comparisons.
20160207 03:48:06< vultraz> i know
20160207 03:48:19< vultraz> will test in a bit
20160207 04:02:10< vultraz> C:\Users\Charles\Documents\wesnoth-git-stable\projectfiles\CodeBlocks\cb\include_tdm_gcc\boost\bind\mem_fn_template.hpp|156|error: pointer to member type 'void (gui2::ttoggle_button::)(gui2::twidget*)' incompatible with object type 'gui2::twidget'|
20160207 04:07:49< vultraz> celticminstrel: ^
20160207 04:13:36< celticminstrel> Does that eventually point to the group_operator() call around line 313 of window.cpp?
20160207 04:13:53< celticminstrel> Because if so, try taking the address of the widget.
20160207 04:19:43< vultraz> '&this'?
20160207 04:20:08< celticminstrel> I'm talking about in tgroup::execute_group_actions()
20160207 04:20:36< vultraz> oh
20160207 04:20:50< celticminstrel> Basically the error looks like you're trying to pass a reference to a function that expects a pointer.
20160207 04:24:06< vultraz> isn't the problem that you're passing the hidden argument to group_operator as a twidget*
20160207 04:24:49< celticminstrel> Hmm?
20160207 04:25:57< vultraz> you said to do this: boost::bind(&ttoggle_button::group_operator, _1, this)
20160207 04:26:33< celticminstrel> Yes.
20160207 04:28:43< vultraz> does that mean, when passed to boost::function<void(twidget*)>, that you're basically calling it as (twidget*)::group_operator(this) or however the hidden argument syntax works
20160207 04:30:02< celticminstrel> It means that group_operator(&widget) leads to a call to widget.group_operator(clicked_button).
20160207 04:30:47< vultraz> but we don't want &widget
20160207 04:30:53< celticminstrel> Why not?
20160207 04:31:00< vultraz> i thought we wanted a pointer
20160207 04:31:05< celticminstrel> That is a pointer.
20160207 04:31:35< celticminstrel> I imagine you're getting confused by the fact that * and & have different meanings in different contexts.
20160207 04:32:32< celticminstrel> As part of a type name, & means a reference, but as an operator it's address-of (meaning it returns a pointer). I'm pretty sure you've been told this at least three times already.
20160207 04:32:40< vultraz> right, ys
20160207 04:32:44< vultraz> I know that
20160207 04:32:51< vultraz> i thought you meant ...
20160207 04:32:52< celticminstrel> So &widget is a pointer.
20160207 04:32:53< vultraz> nevermind
20160207 04:33:09< vultraz> I thought you were saying it was passing a reference  
20160207 04:33:14< celticminstrel> If I'd meant it as a prototype with a reference argument, it would've been widget^
20160207 04:33:20< celticminstrel> ^ widget&
20160207 04:33:48< celticminstrel> Well, probably twidget& in this specific case though.
20160207 04:57:09-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160207 05:03:49< iceiceice> hehe
20160207 05:04:02< vultraz> hm?
20160207 05:04:05< iceiceice> i wrote a small proposal to modify the C++ standard and sent it to the standard proposals mailing list,
20160207 05:04:07-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160207 05:04:14< iceiceice> i got like 30 replies, now i have to read them all T_T
20160207 05:04:28< celticminstrel> What kind of proposal?
20160207 05:04:38< iceiceice> my proposal is that,
20160207 05:05:03< iceiceice> currently according to the standard, if control flows runs off the end of a non-void function, the result is undefined behavior
20160207 05:05:12< iceiceice> what i propose is that std::terminate should be called instead
20160207 05:05:34< iceiceice> in the proposal i argue that this can be done without impacting the performance of most programs
20160207 05:06:00< vultraz> celticminstrel: btw, I can't take the address of 'widget' because it still doesn't work
20160207 05:06:08< iceiceice> basically by injecting a call to std::terminate at the end of every function, and relying on the optimizer to remove it in most cases, so long as it can prove that it is dead code
20160207 05:06:33< iceiceice> i think that in "typical" code that will work
20160207 05:06:54< celticminstrel> Are you sure you're doing what I said?
20160207 05:08:29< vultraz> well if you meant either "FOREACH(AUTO & widget, members_)" or "group_operator(widget);
20160207 05:08:37< vultraz> &widget^
20160207 05:08:43< vultraz> both don't work
20160207 05:09:00< celticminstrel> The second one.
20160207 05:09:14< celticminstrel> But why is there a ^ there?
20160207 05:09:20< celticminstrel> Oh right, never mind.
20160207 05:09:29< celticminstrel> Correction.
20160207 05:09:48< celticminstrel> So does it still give the same error, or a different one?
20160207 05:10:46< vultraz> gives more errors
20160207 05:10:48< vultraz> http://pastebin.com/ghHXEgQJ
20160207 05:11:43< celticminstrel> Okay, so I was wrong. That's not the cause of the error.
20160207 05:12:11< celticminstrel> How does that differ from the error before you added the &?
20160207 05:15:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160207 05:15:46< vultraz> previously only
20160207 05:16:03< vultraz> error: pointer to member type 'void (gui2::ttoggle_button::)(gui2::twidget*)' incompatible with object type 'gui2::twidget'|
20160207 05:16:04< vultraz> error: return-statement with a value, in function returning 'void' [-fpermissive]|
20160207 05:19:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160207 05:26:28< celticminstrel> Ah, so the original error is somehow unrelated. Hmm.
20160207 05:27:51< celticminstrel> Ah, I think I get it.
20160207 05:31:42< celticminstrel> I can't see a good solution short of scrapping the premise that arbitrary widgets be allowed in a group.
20160207 05:32:01< celticminstrel> However, I think it would be reasonable for the group to have a list of tselectable_ rather than twidget.
20160207 05:32:31< celticminstrel> or ttoggle_button.
20160207 05:39:52< vultraz> celticminstrel: that seems reasonable. 
20160207 05:40:06< vultraz> or what about a template
20160207 05:40:58< celticminstrel> If you want a template, I think you'd need it to be a template class, which wouldn't interact well with having a list of all groups in the twindow.
20160207 05:41:10< vultraz> template class?
20160207 05:41:22< celticminstrel> As opposed to a template function.
20160207 05:41:39< celticminstrel> ie, make tgroup a template.
20160207 05:41:47< celticminstrel> But that means you can't have a list of tgroups in the window.
20160207 05:42:00< celticminstrel> Unless you do some extra work.
20160207 05:42:20< vultraz> well the list needs to be there :/
20160207 05:50:25< vultraz> I don't even know how to use class templates]
20160207 05:50:32< vultraz> ive only used function templates
20160207 05:50:49< celticminstrel> You've used class templates.
20160207 05:51:09< celticminstrel> std::vector, boost::function, and a lot of other standard classes are class templates.
20160207 05:51:31< vultraz> oh?
20160207 05:51:36< vultraz> is that why they use < >
20160207 05:51:42< celticminstrel> Yes.
20160207 05:52:24< celticminstrel> I personally think it's better to choose the other route, since you don't actually have a use-case for arbitrary widgets in a group.
20160207 05:53:14< vultraz> so make groups a vector of tselectable_?
20160207 05:53:23< celticminstrel> Yeah.
20160207 05:53:35< celticminstrel> Rather than a vector of twidget.
20160207 05:54:09< celticminstrel> I think that change alone (and changing twidget to tselectable_ in a few other places) would make what you have now compile.
20160207 05:54:48< celticminstrel> Though I think it'd be better if it could be done without any modifications to ttoggle_button - ie, put everything needed in tselectable_ instead. But, that might not be possible.
20160207 05:56:40< vultraz> why not?
20160207 05:57:51< celticminstrel> Ooooh, tselectable_ has set_callback_state_change, so maybe it would be possible...
20160207 05:59:24< celticminstrel> Or maybe not. It's pure virtual, so utilizing that would still mean changes to ttoggle_button.
20160207 05:59:34< vultraz> I don't mind changing toggle button
20160207 06:00:01< celticminstrel> Yeah, I think it can't be avoided.
20160207 06:00:11< vultraz> if you're suggesting restricting this to tselectable_, I should probably move the tgroup class definition there too
20160207 06:00:17< vultraz> (same file)
20160207 06:04:34< vultraz> error: pointer to member type 'void (gui2::ttoggle_button::)(gui2::tselectable_*)' incompatible with object type 'gui2::tselectable_'| oh come on 
20160207 06:06:39< celticminstrel> You have something like &ttoggle_button::group_operator, right?
20160207 06:07:01< vultraz> no... should I?
20160207 06:07:14< celticminstrel> Uh... I'm referring to the bind line.
20160207 06:07:25< vultraz> oh
20160207 06:07:27< vultraz> yes
20160207 06:09:48< celticminstrel> Okay, change that to tselectable_
20160207 06:13:23< vultraz> ok, so that needs to be moved to tselectable... 
20160207 06:13:38< vultraz> ok I might as well just move this to that class
20160207 06:16:14< celticminstrel> I think that's probably not a good idea, actually.
20160207 06:16:31< celticminstrel> Does that implementation make sense for a tristate button, for example?
20160207 06:16:42< vultraz> what is a tristate button
20160207 06:16:47< celticminstrel> I don't know.
20160207 06:16:59< celticminstrel> But according to comments in selectable.hpp, it's a thing that exists.
20160207 06:17:04< vultraz> I looked at the commit that added them and I can't understand it
20160207 06:18:39< vultraz> but i assume if someone wants to use groups for tristates, fine
20160207 06:19:41< celticminstrel> What I was going to suggest was to make group_operator pure virtual in tselectable_.
20160207 06:20:33< vultraz> that's what I was going to do
20160207 06:39:56-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160207 07:21:55-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160207 07:33:13-!- Kwandulin [~Miranda@p200300760F0BC535E0568D141D27C494.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160207 07:42:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160207 07:47:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20160207 08:33:16-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160207 08:33:41-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 245 seconds]
20160207 08:33:42-!- wedge010 is now known as wedge009
20160207 08:52:55-!- Kwandulin [~Miranda@p200300760F0BC535E0568D141D27C494.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
20160207 10:08:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160207 10:09:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160207 10:09:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160207 10:09:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160207 10:14:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 245 seconds]
20160207 10:52:46-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160207 11:28:06-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160207 11:29:56-!- mjs-de [~mjs-de@x5ce483a1.dyn.telefonica.de] has joined #wesnoth-dev
20160207 11:46:58-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds]
20160207 12:00:13-!- Kwandulin [~Miranda@p200300760F0BC535C1C86D7D49CB2B90.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160207 12:07:44-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160207 12:15:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160207 12:23:36-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 272 seconds]
20160207 12:32:28-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160207 12:33:40-!- Kwandulin [~Miranda@p200300760F0BC535C1C86D7D49CB2B90.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds]
20160207 12:35:09< zookeeper> eh. when i use the mousewheel to scroll the editor's terrain palette, the map scrolls down too.
20160207 12:39:12-!- gfgtdf [~chatzilla@f054133106.adsl.alicedsl.de] has joined #wesnoth-dev
20160207 12:39:50< gfgtdf> vultraz: tselectable_ more or less means 'toggle_button or toggle_panel'.
20160207 12:41:02< gfgtdf> vultraz: tristate buttons are teh toggle buttons that are used for the psorting headers in listboxes, in this case they can have these 3 states: 'dont sort' , 'sort up' and 'sort down'
20160207 12:51:29-!- irker318 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160207 12:51:29< irker318> wesnoth: Lari Nieminen wesnoth:master 72100d866faa / data/core/terrain-graphics/new-macros.cfg: Remove some unnecessary uses of * in rule maps https://github.com/wesnoth/wesnoth/commit/72100d866faab4f406c91118aea18c6b027807af
20160207 12:55:16-!- Kwandulin [~Miranda@p200300760F0BC54CC1C86D7D49CB2B90.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160207 13:08:36-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160207 13:09:12< vultraz> gfgtdf: hm ok
20160207 14:35:48-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 250 seconds]
20160207 15:17:13< zookeeper> huh, hmmh. with new builds with SDL2 and all, there's quite a noticeable memory use increase. in one case, it goes from 420mb to 550mb.
20160207 15:22:12< vultraz> yeah
20160207 15:22:16< vultraz> and cpu cycles
20160207 15:47:08-!- gfgtdf [~chatzilla@f054133106.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
20160207 15:51:41-!- irker318 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160207 15:53:39-!- Kwandulin [~Miranda@p200300760F0BC54CC1C86D7D49CB2B90.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160207 16:19:07-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160207 16:27:20-!- Kwandulin [~Miranda@p200300760F0BC54C0D59963B840ED9C5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160207 16:41:41< vultraz> celticminstrel: i got it working
20160207 16:42:02< vultraz> https://github.com/Vultraz/wesnoth/commit/cc15c6dce2ce5347538f9bb8977bff2fcbb40313
20160207 16:43:30< vultraz> I am now attempting to make it use boost::shared_ptr
20160207 16:43:50< celticminstrel> Fun!
20160207 16:45:11< vultraz> not really 
20160207 16:45:13< vultraz> :P
20160207 16:49:10< vultraz> (emphasis on "attempting")
20160207 16:50:47< vultraz> I'm assuming "typedef boost::shared_ptr<tselectable_> tgroup_ptr;" is the right way to do this
20160207 16:51:31< celticminstrel> I don't know about right way, but reasonable certainly.
20160207 16:51:58< vultraz> I was following this https://stackoverflow.com/questions/3476938/example-to-use-shared-ptr
20160207 16:58:14< vultraz> What's this about "the important things about shared_ptr's is to only ever construct them with the following syntax: shared_ptr<Type>(new Type(...));"
20160207 16:58:52< celticminstrel> I'd say that's reasonable too.
20160207 17:00:59< vultraz> so is like
20160207 17:01:01< vultraz> 	tgroup_ptr new_group = new tgroup(id);
20160207 17:01:03< vultraz> 	groups_.push_back(new_group);
20160207 17:01:04< vultraz> not right?
20160207 17:01:19< celticminstrel> Obviously. It won't compile.
20160207 17:01:26< vultraz> bc the answer above was saying "it is a best practice to allocate into a free-standing object instead of a temporary"
20160207 17:01:36< vultraz> (also it does seem to compile)
20160207 17:01:44< vultraz> well, that part does
20160207 17:01:54< celticminstrel> Oh, I misread.
20160207 17:02:25< celticminstrel> "tgroup_ptr new_group = new tgroup(id)" is semantically identical to that recommended syntax.
20160207 17:03:58< vultraz> ok
20160207 17:04:02< vultraz> almost got it building...
20160207 17:05:15< vultraz> ttoggle_panel and tselectable_ can't find tgroup_ptr... even though it's a public typedef in tgroup and I forward declared that :| 
20160207 17:07:00< vultraz> is it supposed to be outside the class... ?
20160207 17:16:35< vultraz> what do you mean it's not declared :|
20160207 17:21:54-!- irker356 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160207 17:21:54< irker356> wesnoth: Nils Kneuper wesnoth:master 84ff8f4d969b / / (26 files in 25 dirs): updated Galician translation https://github.com/wesnoth/wesnoth/commit/84ff8f4d969b02fdc7d3fed7fc75e1fdb517231d
20160207 17:25:37< celticminstrel> vultraz: It wouldn't make any sense for tgroup_ptr to be inside tgroup. If it were, you'd have to write tgroup::tgroup_ptr to use it.
20160207 17:25:57< celticminstrel> Also, you can't use anything that's inside a class that's only forward declared.
20160207 17:29:37< vultraz> celticminstrel: so I should keep it outside the class?
20160207 17:30:29< celticminstrel> Yes.
20160207 17:30:40< vultraz> *groans*
20160207 17:35:42-!- gfgtdf [~chatzilla@f054133106.adsl.alicedsl.de] has joined #wesnoth-dev
20160207 17:38:58< vultraz> error: no match for 'operator==' (operand types are 'gui2::ttoggle_button*' and 'gui2::tgroup_ptr {aka boost::shared_ptr<gui2::tselectable_>}')|
20160207 17:39:03< vultraz> herm
20160207 17:39:12< vultraz> celticminstrel: what do I do here?
20160207 17:39:31< vultraz> I'm not sure how you deal with this
20160207 17:39:37< celticminstrel> Where is this?
20160207 17:39:42< celticminstrel> In group_operator?
20160207 17:40:02< vultraz> yes, ttoggle_button::group_operator
20160207 17:40:04< vultraz> the set_value(this == button); line
20160207 17:40:09< celticminstrel> button.get()
20160207 17:40:17< celticminstrel> That returns the raw pointer.
20160207 17:40:52< celticminstrel> Also, use the static_cast there like I mentioned before.
20160207 17:41:12< celticminstrel> Now that you're using tselectable_ it'll likely be actually necessary.
20160207 17:41:12< vultraz> on this?
20160207 17:41:16< celticminstrel> Yeah.
20160207 17:41:44< vultraz> i sure hope all this makes this code safer 
20160207 17:42:06< vultraz> (including the switching of 'this' and '_1')
20160207 17:42:11< celticminstrel> tselectable_ is the second parent class of ttoggle_button, so if you have a pointer to tselectable_ and a pointer to twidget that point to the same ttoggle_button, those two pointers will probably not compare equal even though they point to the same thing.
20160207 17:43:40< celticminstrel> Well, since tselectable_ has no data, you could be lucky, but... there's still the vptr...
20160207 17:49:39-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160207 17:51:22< vultraz> I need to call tgroup_ptr something different
20160207 17:51:30< vultraz> im confusing myself with the name >_>
20160207 18:05:00< vultraz> celticminstrel: how would I convert a tselectable_* object to a boost::shared_ptr<tselectable_> object?
20160207 18:05:14< vultraz> is that what " shared_ptr<Type>(new Type(...))" is?
20160207 18:06:00< celticminstrel> Where are you doing this?
20160207 18:06:22< celticminstrel> And why would you call tgroup_ptr anything other than tgroup_ptr?
20160207 18:06:38< vultraz> I was going to change it to tgroup_member_ptr
20160207 18:06:57< celticminstrel> Oh wait.
20160207 18:07:11< celticminstrel> Yeah, call it tselectable_ptr or something.
20160207 18:10:23< vultraz> anyway, add_member takes a tselectable and needs to push it to the vector of tselectable_ptr's
20160207 18:13:01< vultraz> would I just say members_.push_back(tselectable_ptr(widget));
20160207 18:14:05< vultraz> hm
20160207 18:14:09< vultraz> apparently not
20160207 18:14:45< vultraz> celticminstrel: ^
20160207 18:15:11< celticminstrel> Uhh, where'd that widget come from though?
20160207 18:15:21< celticminstrel> Did you allocate it with new?
20160207 18:15:42< vultraz> er
20160207 18:15:48< vultraz> widget is the argument passed
20160207 18:15:54< celticminstrel> Where is this?
20160207 18:15:55< vultraz> it's called from add_to_group
20160207 18:16:19< celticminstrel> You can't put that in a shared_ptr.
20160207 18:16:24< vultraz> D:
20160207 18:16:26< celticminstrel> It might cause it to be deleted early.
20160207 18:16:31< vultraz> so what do I do
20160207 18:17:14< celticminstrel> In practice it probably won't, but...
20160207 18:17:33< celticminstrel> It could lead to a double delete when the dialog is disposed.
20160207 18:17:53< vultraz> what happens then
20160207 18:18:15< celticminstrel> Well, I guess the problem is that shared_ptr owns its object.
20160207 18:18:28< celticminstrel> But in add_to_group, the widget isn't owned by the group, right?
20160207 18:18:40< celticminstrel> (Which class is add_to_group in again?)
20160207 18:18:48< vultraz> twindow
20160207 18:18:59< celticminstrel> (And members_ is in twindow?)
20160207 18:19:13 * celticminstrel is a little confused here.
20160207 18:19:16< vultraz> no, groups_ is in twindow, which is a tgroup vector
20160207 18:19:28< vultraz> each tgroup has a members_ vector, which is of tselectable_ptr
20160207 18:19:33< celticminstrel> Oh, right, add_member, not add_to_group.
20160207 18:19:39< vultraz> (aka boost::shared_ptr<tselectable_>)
20160207 18:19:48< celticminstrel> I thought we were talking about add_to_group.
20160207 18:19:54< celticminstrel> Okay so...
20160207 18:20:23< vultraz> twindow::add_to_group() iterates over groups and call the relevant one's add_member member
20160207 18:20:23< celticminstrel> The window does own the widget, which means that if you wanted to pass it around as a shared pointer, you'd need to obtain a shared pointer from some function in twindow.
20160207 18:21:06< celticminstrel> If twindow doesn't already have such a function, maybe it's not worth using shared pointers for the selectable objects.
20160207 18:21:14< vultraz> ................................................
20160207 18:21:34< vultraz> I thought you were the one who said this would be safer and guard against deletion of the widget pointers
20160207 18:21:59< celticminstrel> Yeah, it would, but... wait... did I say it that way?
20160207 18:22:39< vultraz> plus all the docs I'm reading indicate that this means i wouldn't have to walk the vector to delete stale pointers
20160207 18:22:54< celticminstrel> You're doing that?
20160207 18:22:57< vultraz> no
20160207 18:23:08< vultraz> I'm doing *this* to *avoid* doing *that*
20160207 18:23:54< celticminstrel> Okay so... I see in the logs that you were worried about the possibility of a widget in the group being deleted while the group is still functioning.
20160207 18:25:54< celticminstrel> Are widgets commonly deleted before the dialog is closed?
20160207 18:26:33< vultraz> I'm not sure
20160207 18:26:35 * celticminstrel imagines advanced preferences would do this, if nothing else.
20160207 18:26:42< vultraz> well, that, for one
20160207 18:26:59< vultraz> but I want to guard against the possibility
20160207 18:27:25< celticminstrel> I haven't looked at GUI2 in much detail. Does it use plain pointers everywhere?
20160207 18:27:54< vultraz> mostly...
20160207 18:28:00< vultraz> some dialogs use shared_ptrs for some reason
20160207 18:28:16< celticminstrel> Well, in the core framework, I mean.
20160207 18:28:27< celticminstrel> Specific dialogs are irrelevant.
20160207 18:28:30< vultraz> not... really, no
20160207 18:28:44< vultraz> not at all, actually
20160207 18:28:44< celticminstrel> :/
20160207 18:29:42< vultraz> couple of uses of dynamic_pointer_cast
20160207 18:29:57< celticminstrel> That implies shared_ptr
20160207 18:29:58< vultraz> actually, a lot of uses
20160207 18:30:37< celticminstrel> Maybe the shared pointers are typedef'd?
20160207 18:31:00< vultraz> I'm grepping for 'shared_ptr' and only getting dialog stuff (plus my usecase)
20160207 18:31:21< celticminstrel> If they were typedef'd you'd at least get the typedef declaration...
20160207 18:32:11< celticminstrel> But if it's using dynamic_pointer_cast, then it must be using shared_ptr...
20160207 18:32:15< vultraz> I see intrusive_ptrs
20160207 18:32:25< celticminstrel> Oh.
20160207 18:33:08< vultraz> 49 cases of such
20160207 18:33:25< vultraz> mostly... for the tresolution class
20160207 18:33:32< vultraz> and its accessors
20160207 18:33:35< celticminstrel> Ah.
20160207 18:34:14< celticminstrel> So intrusive_ptr is not used for widgets?
20160207 18:34:54< vultraz> well...
20160207 18:34:57< vultraz> I guess not
20160207 18:35:03< vultraz> most of the uses are like so
20160207 18:35:05< vultraz> 	boost::intrusive_ptr<const ttoggle_panel_definition::tresolution> conf
20160207 18:35:07< vultraz> 			= boost::dynamic_pointer_cast<const ttoggle_panel_definition::
20160207 18:35:08< vultraz> 												  tresolution>(config());
20160207 18:35:12< vultraz> which I don't understand in the least
20160207 18:35:14< vultraz> :P
20160207 18:35:20< celticminstrel> Okay.
20160207 18:39:37< vultraz> so do I need to use a shared pointer vector or not?
20160207 18:40:32< celticminstrel> I think it would be good to do so, but I think it's impossible to do it properly when shared pointers aren't used throughout the framework, so my recommendation is to forget about it. Sorry.
20160207 18:40:49< vultraz> Alright ;_;
20160207 18:41:12< celticminstrel> Even weak_ptr won't work, because it relies on shared_ptr.
20160207 18:41:49< vultraz> so I just have to cross my fingers and hope nothing breaks in the future
20160207 18:41:52< celticminstrel> Will you need groups that contain temporary widgets?
20160207 18:41:58< vultraz> no
20160207 18:42:04< celticminstrel> Hmm, well...
20160207 18:42:12< celticminstrel> Is there a way to delete or empty out a group?
20160207 18:42:17< vultraz> not yet
20160207 18:42:22< vultraz> I should implement that...
20160207 18:42:24< celticminstrel> Or indeed, to remove a specific widget?
20160207 18:42:33< vultraz> no
20160207 18:42:42< vultraz> I will implement that
20160207 18:42:45< vultraz> so like
20160207 18:42:48< vultraz> remove_from_group
20160207 18:42:50< vultraz> remove_group
20160207 18:42:54< vultraz> and get_group
20160207 18:43:09< celticminstrel> Having that would help with the possibility of a widget being deleted while in the group - allowing whoever deletes the widget to clean up the group manually.
20160207 18:43:25< vultraz> (for the last I don't need an iterator, I can just return a pointer to that group in the vector, I think)
20160207 18:43:52< vultraz> celticminstrel: calling remove_from_group in the destructor?
20160207 18:45:26< vultraz> (I'm still confused as to when you should get iterators and when you should get pointers)
20160207 18:45:34< vultraz> (especially bc one is like the other)
20160207 18:47:52< vultraz> I'm not even sure why I made these vectors of pointers and not references
20160207 18:48:05< vultraz> since neither actually copies the object
20160207 18:49:12< vultraz> but there seems to be some more fineness than just 'if can be null pointer else reference'
20160207 19:04:54-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 250 seconds]
20160207 19:24:58-!- timotei__ is now known as timotei
20160207 19:37:24< celticminstrel> Don't forget that, when removing a widget from the group, that widget needs to set its pointer to containing group to null.
20160207 19:37:37< celticminstrel> [Feb 07@1:47:52pm] vultraz: I'm not even sure why I made these vectors of pointers and not references
20160207 19:37:46< celticminstrel> Because a vector of references would not compile.
20160207 19:38:04< celticminstrel> References don't satisfy all the constraints required for storage in a vector.
20160207 19:38:24< celticminstrel> I forget exactly which constraints they fail.
20160207 19:39:01< vultraz> so you can either have a vector of objects or a vector of pointers
20160207 19:39:57< celticminstrel> [Feb 07@1:45:26pm] vultraz: (I'm still confused as to when you should get iterators and when you should get pointers)
20160207 19:39:58< celticminstrel> If you're working with a collection of objects (like a vector, list, deque, map, set, or array), then you want an iterator. If you're dealing with a single object, then you want a reference. A pointer can serve both purposes.
20160207 19:40:14< celticminstrel> vultraz: You can have a vector of objects, but that denies polymorphism.
20160207 19:40:25< celticminstrel> A vector<tselectable_> cannot store a ttoggle_button.
20160207 19:40:40< celticminstrel> It can't store anything actually, since tselectable_ is abstract. It probably wouldn't compile.
20160207 19:40:46< vultraz> ahhh
20160207 19:41:07< celticminstrel> Basically, if it's not a pointer, you can only store that exact type, no subclasses allowed.
20160207 19:41:30< vultraz> so for get_group, I could either get an iterator or just a pointer 
20160207 19:42:28< celticminstrel> I think a pointer is better there - the collection is not something that the caller needs to know about.
20160207 19:42:55< celticminstrel> The caller just wants a reference to the group with the specified ID - it doesn't care that the group happens to be stored in a collection.
20160207 19:43:10< celticminstrel> BTW, I just suddenly realize - you're storing the groups in a vector?
20160207 19:43:13< celticminstrel> ^realized
20160207 19:43:46< vultraz> why not?
20160207 19:43:49< vultraz> so you can iterate over them
20160207 19:44:13< celticminstrel> Uh, think about it. Each one has a unique ID, and when you look up a specific group, you're searching for an ID.
20160207 19:44:18< celticminstrel> That's an obvious use case for a map.
20160207 19:45:51< vultraz> I don't have much experience working with maps..
20160207 19:45:53< celticminstrel> If you have a map<string,tgroup> groups_, then you can add a new group with groups[new_id] = new_group. (If there was already a group by that ID though, it would be overwritten, so you need to account for that possibility.)
20160207 19:46:04< vultraz> vectors are my goto 'list-type' object
20160207 19:46:13< celticminstrel> You can get the group with a specific ID with groups_[desired_id].
20160207 19:46:23< celticminstrel> You've used tables in Lua, haven't you?
20160207 19:47:02< celticminstrel> A map is an associative array.
20160207 19:47:33< celticminstrel> Similar to a Lua table.
20160207 19:47:51-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160207 19:48:08< celticminstrel> If you need to look up things by name, or similar key-lookups, a map is much better than a linear collection (vector, list, deque, array, etc).
20160207 19:48:43< celticminstrel> (A map is implemented as a tree in C++. Maps can also be implemented as a hashtable, but you need C++11 for that.)
20160207 19:48:56< celticminstrel> (It's called unordered_map.)
20160207 19:50:31-!- ancestral [~ancestral@209.181.254.220] has quit [Client Quit]
20160207 19:51:26< vultraz> from the sound of it, is the config class implemented with maps?
20160207 19:51:41< celticminstrel> Yeah, maps and variants.
20160207 19:51:56< celticminstrel> I think it's like a map<string,variant>.
20160207 19:52:33< celticminstrel> Though variant is also a template, so it's a bit more complicated than that.
20160207 19:53:07< vultraz> that seems like a horribly inefficient class...  (config, that is)
20160207 19:53:10< celticminstrel> Anyway, the variant bit isn't important. It's a map, yes.
20160207 19:53:14< celticminstrel> Why?
20160207 19:53:55-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has quit [Ping timeout: 240 seconds]
20160207 19:54:07< celticminstrel> What seems inefficient about it?
20160207 19:54:16< vultraz> the idea of storing All Of The Data in maps
20160207 19:54:46< vultraz> when you could have scripts
20160207 19:54:49< celticminstrel> Well, config is more complicated than just a map, but the attributes are stored as a map, at least.
20160207 19:55:02< celticminstrel> I don't really get what you're going for.
20160207 19:55:13< celticminstrel> I don't see how scripts have anything to do with it.
20160207 19:56:58< vultraz> just wondering if the game would be more efficient if the data were parsed as scripts rather than converting it to maps and then having all the parsing and lookup
20160207 19:59:07< celticminstrel> Parsing is involve either way.
20160207 19:59:10< celticminstrel> ^involved
20160207 19:59:45< celticminstrel> Lookup in a tree-map is O(log n) as I recall, which probably doesn't mean anything to you but basically means it's fairly fast.
20160207 20:00:54< celticminstrel> Lookup in a hashmap though is O(1) in best case, which is even faster, but O(n) in worst case, which is slower. So perhaps config could be changed to a hashmap if and when we move to C++11.
20160207 20:04:07-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160207 20:08:09< gfgtdf> celticminstrel: well i dont think whether to use hashmap is relate to using c++11
20160207 20:08:39< gfgtdf> celticminstrel: also note taht 'normal' maps have teh advantage of giving th elements in sorted order when iterating over them
20160207 20:09:25< gfgtdf> celticminstrel: iirc we once tried to use a hashmap for the unit map, but it broke a lot of addons that assumed the current order when using [store_unit](s)
20160207 20:09:50< celticminstrel> gfgtdf: I was talking abotu config, not the unit map.
20160207 20:10:01< gfgtdf> celticminstrel: yes i know
20160207 20:10:02< celticminstrel> You're right that C++11 isn't required to use a hashmap, of course.
20160207 20:10:12< celticminstrel> But C++11 includes a hashmap in the standard library.
20160207 20:10:17< celticminstrel> ^about
20160207 20:10:40< gfgtdf> celticminstrel: but the same still aplies if doce assumes rteh curent order whe  iterating over config attributes
20160207 20:10:53< celticminstrel> Do configs rely on attribute ordering? I think the wiki says you shouldn't rely on it.
20160207 20:11:07< gfgtdf> celticminstrel: boost shoudl also have a hasmap, mostlikeley the std haspmap is just copied from that
20160207 20:11:13< celticminstrel> Probably.
20160207 20:11:39< gfgtdf> celticminstrel: well i know that for example the wesnothd server rejects config packages that have the attributes in a wrong order
20160207 20:11:55< celticminstrel> Why?
20160207 20:12:08< gfgtdf> (afaik it isnt even posssible to iterate over config attributes in wml)
20160207 20:12:18< gfgtdf> celticminstrel: for effeciency reasons afaik
20160207 20:12:55< celticminstrel> [Feb 07@3:12:08pm] gfgtdf: (afaik it isnt even posssible to iterate over config attributes in wml)
20160207 20:12:56< celticminstrel> Huh? I'm pretty sure it is.
20160207 20:13:06< gfgtdf> celticminstrel: how ?
20160207 20:13:19< gfgtdf> celticminstrel: well in lua maybe
20160207 20:13:24< celticminstrel> Oh right, not with ActionWML perhaps.
20160207 20:13:34< celticminstrel> Definitely in Lua though.
20160207 20:13:58< gfgtdf> celticminstrel: but then it has already converted in into a  lua table which then uses in internal lua table order.
20160207 20:14:05< celticminstrel> Right.
20160207 20:14:11< gfgtdf> celticminstrel: afaik lua tables are already hashtables
20160207 20:14:12< celticminstrel> Unless it's a vconfig.
20160207 20:14:19< gfgtdf> so its mostlikeley not ordered
20160207 20:14:52< gfgtdf> celticminstrel: hmm yes mabye it possible with vconfigs.
20160207 20:22:38-!- irker356 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160207 21:02:21-!- berte [52de7faa@gateway/web/freenode/ip.82.222.127.170] has joined #wesnoth-dev
20160207 21:02:36-!- berte [52de7faa@gateway/web/freenode/ip.82.222.127.170] has quit [Changing host]
20160207 21:02:36-!- berte [52de7faa@unaffiliated/berte] has joined #wesnoth-dev
20160207 21:02:36-!- berte [52de7faa@unaffiliated/berte] has quit [Changing host]
20160207 21:02:36-!- berte [52de7faa@gateway/web/freenode/ip.82.222.127.170] has joined #wesnoth-dev
20160207 21:02:46< berte> hi folks
20160207 21:02:54< gfgtdf> hi
20160207 21:05:19< berte> I saw webpage help needs notice, so is that still available?
20160207 21:05:33< zookeeper> sure
20160207 21:06:28< gfgtdf> yes
20160207 21:08:21< berte> my c++ not great but I can be useful 
20160207 21:08:29< berte> so how can I apply?
20160207 21:10:44< zookeeper> well you don't need to apply, you can just clone the repo and submit pull requests when you got something. but if you mean what should/could you work on, then that rather depends on what sort of thing you're interested in.
20160207 21:11:58< zookeeper> and/or you can try to pick something from https://gna.org/bugs/?group=wesnoth
20160207 21:12:54< berte> thx zookeeper 
20160207 21:14:52-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160207 21:14:53-!- berte [52de7faa@gateway/web/freenode/ip.82.222.127.170] has quit [Quit: Page closed]
20160207 21:16:02-!- berte [~berte@82.222.127.170] has joined #wesnoth-dev
20160207 21:16:15-!- berte [~berte@82.222.127.170] has quit [Changing host]
20160207 21:16:15-!- berte [~berte@unaffiliated/berte] has joined #wesnoth-dev
20160207 21:31:02< zookeeper> berte, anyway, it's good to ask for opinions here on anything you might want to start working on. maybe someone's already doing it, or maybe we don't actually want/need what a bug report is asking for for whatever reason, etc.
20160207 21:34:43< berte> sure zookeeper, I'll take a bug from queue and investigate it 
20160207 21:35:22< berte> before starting investigation I'll inform to channel, is it ok?
20160207 21:36:26< zookeeper> yeah
20160207 21:46:12-!- Kwandulin [~Miranda@p200300760F0BC54C0D59963B840ED9C5.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160207 21:47:24-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160207 22:15:34-!- aidanhs [~aidanhs@81.4.110.234] has quit [Ping timeout: 252 seconds]
20160207 22:19:49-!- aidanhs [~aidanhs@81.4.110.234] has joined #wesnoth-dev
20160207 23:33:29-!- SpoOkyMagician [~chatzilla@cpe-74-136-45-198.kya.res.rr.com] has joined #wesnoth-dev
20160207 23:34:25-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160207 23:56:02-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 252 seconds]
--- Log closed Mon Feb 08 00:00:43 2016