--- Log opened Tue Aug 02 00:00:09 2016
20160802 00:00:12< mattsc> hi vultraz 
20160802 00:00:13< celmin> Meh.
20160802 00:00:42< vultraz> maybe that will happen
20160802 00:00:44< vultraz> who knows
20160802 00:00:51< vultraz> dave is odd
20160802 00:00:58< vultraz> he can do a lot of stuff really fast if he wants to
20160802 00:01:02< mattsc> In master, when you bring up the create unit dialog using shift-C, you can start typing without having to click on the window
20160802 00:01:04< vultraz> but sometimes he just doesn't do stuff
20160802 00:01:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 00:01:14< vultraz> mattsc: yes?
20160802 00:01:22< mattsc> but if you then want to use the cursor keys to select a unit, you have to click on it first.
20160802 00:01:29< vultraz> I know
20160802 00:01:33< mattsc> I find that little ...
20160802 00:01:34< celmin> That needs to be fixed BTW.
20160802 00:01:39< vultraz> can't really do anything about it
20160802 00:01:42< mattsc> okay; that was my question   :D
20160802 00:01:46< celmin> I'm certain that's not true.
20160802 00:01:58< vultraz> i think only one widget can have focus at once
20160802 00:02:09< celmin> It's not really a question of widget focus.
20160802 00:02:19< mattsc> well, in 1.12 it worked that way
20160802 00:02:19< iceiceice> vultraz, making things into modules is important
20160802 00:02:23< iceiceice> it helps with maintainability
20160802 00:02:28< vultraz> yes, I like modules
20160802 00:02:39< iceiceice> its not a race :)
20160802 00:02:39< mattsc> as in, I could just use the keyboard for all of that, without having to use my mouse
20160802 00:02:45< vultraz> iceiceice: tbh id like to split some of wesnoth's codebase into modules. like the generator stuff.
20160802 00:02:58< celmin> Separating out a libwml module would be great. (Though it's hard because of t_string.)
20160802 00:03:02< iceiceice> i dont think it needs like, git submodules, those things seem kind of horrible
20160802 00:03:12< iceiceice> but like, stand alone libraries would be a good thing
20160802 00:03:28< celmin> For MSVC you'd have a separate project for each module. For XCode, a separate target.
20160802 00:03:59< vultraz> mattsc: celmin: so the thing is subsequent keyboard_capture calls override the previous ones
20160802 00:04:11< vultraz> so if i set focus to the list, i cant on the filter box
20160802 00:04:12< celmin> keyboard_capture?
20160802 00:04:22< vultraz> twindow::keyboard_capture
20160802 00:04:24< vultraz> i think
20160802 00:04:45< celmin> What's it do?
20160802 00:04:58< vultraz> give a widget focus for keystrokes
20160802 00:05:12< mattsc> vultraz: I know that this is not very high on the priority list, as most people won’t use it extensively.  I just find it amazingly inconvenient for such a small thing.
20160802 00:05:27< celmin> vultraz: But Esc for example still works as a shortcut.
20160802 00:05:41< vultraz> that's a window thing
20160802 00:05:42< mattsc> It’s funny how a little thing like that, that takes about an extra 0.75 seconds, can be so annoying  ;)
20160802 00:06:08< mattsc> anyways, I just wanted to know whether you are aware of that
20160802 00:06:40< vultraz> oh
20160802 00:06:41< vultraz> wait
20160802 00:06:43< vultraz> ah!
20160802 00:06:49< vultraz> there IS a function to do what we want!
20160802 00:07:41< celmin> Oh?
20160802 00:09:49< irker738> wesnoth: Charles Dang wesnoth:master 7c45df4b6ddc / src/gui/dialogs/ (unit_create.cpp unit_recall.cpp): tunit_create, tunit_recall: give simultaneous keyboard focus to filter textbox a https://github.com/wesnoth/wesnoth/commit/7c45df4b6ddc465de5ff5795c4444d8cbad333b1
20160802 00:09:52< vultraz> mattsc: ^ see if that works
20160802 00:11:34< vultraz> next thing I need to do... make tlabel links work with arbitrary functions.
20160802 00:12:25< celmin> ?
20160802 00:12:27-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 00:12:28< travis-ci> wesnoth/wesnoth#10053 (master - 7cdffec : Charles Dang): The build is still failing.
20160802 00:12:28< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149046605
20160802 00:12:28-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 00:12:43< vultraz> celmin: labels can open browser links
20160802 00:12:47< vultraz> if you click on them
20160802 00:12:53< vultraz> want to make them take functions
20160802 00:13:01< vultraz> iceiceice implemented the link think
20160802 00:13:04< vultraz> thing
20160802 00:13:10< celmin> Example usecase?
20160802 00:13:21< vultraz> COC in the mp lobby?
20160802 00:13:39< iceiceice> celmin, its super useful if you play mp games
20160802 00:13:50< iceiceice> its very common that peopl ewant to be able to send links to eachother
20160802 00:14:03< iceiceice> but because of all the crappy gui1 dialogs, you cant even drag select the text
20160802 00:14:04< vultraz> so what im going to do is
20160802 00:14:15< vultraz> move the link opening code to a function
20160802 00:14:16< celmin> I mean for making them functions rather than links.
20160802 00:14:20< iceiceice> oh
20160802 00:14:21< vultraz> bind it to the callbackk
20160802 00:14:29< celmin> Maybe I misunderstood something though, I dunno.
20160802 00:14:33< vultraz> then add the ability to override
20160802 00:14:48< vultraz> with another function
20160802 00:14:49< iceiceice> celmin, i've been in several games where peopl eused the following hack:
20160802 00:14:54< vultraz> so links always call a function
20160802 00:14:56< iceiceice> 1.) observer wants to send a youtube link
20160802 00:15:02< iceiceice> 2.) player gives control temporarily to observer
20160802 00:15:04< vultraz> but the default function is to open a browser link
20160802 00:15:08< iceiceice> 3.) observer sets a map label with the link
20160802 00:15:17< iceiceice> 4.) all players can use the edit map label dialog to copy paste the text
20160802 00:15:25< iceiceice> 5.) observer gives control back
20160802 00:15:37< vultraz> iceiceice: that is horrible
20160802 00:15:39< iceiceice> hehehe
20160802 00:15:45< celmin> I'm asking vultraz about the usefulness of what he's doing...
20160802 00:15:50< vultraz> oh
20160802 00:15:54< iceiceice> i see, i misread what you were asking
20160802 00:16:03< iceiceice> but i do like telling that story :)
20160802 00:16:06< vultraz> celmin: so I can make the name/type thing in the unit_preview_pane clickable to open the unit's help page
20160802 00:16:10< vultraz> instead of a dedicated button
20160802 00:16:23< celmin> Ah.
20160802 00:16:54< vultraz> having it as a small button (https://drive.google.com/file/d/0B-mR9s8FduLLd0RTTXFCN2tyVjA/view?usp=sharing) is less offensive but
20160802 00:16:59< vultraz> it still sticks out
20160802 00:17:31< vultraz> tho
20160802 00:17:42< vultraz> bad thing is idk how to make links give some visual indication they're links
20160802 00:18:44< celmin> Blue and underlined, obviously. Though, I'm not sure if I like this idea...
20160802 00:18:55< celmin> Another idea is dotted underline.
20160802 00:19:12< celmin> I don't see any problem with having the ? button.
20160802 00:20:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160802 00:25:13< iceiceice> i think this is the hardest TMP problem I ever attempted
20160802 00:25:24< iceiceice> i tried like twice now to do multivisitation of visitors
20160802 00:25:35< iceiceice> using variadic templates, i think this way will work :D
20160802 00:25:44< iceiceice> *multivisitation of variants
20160802 00:25:55< iceiceice> but its pretty complicated now
20160802 00:26:03< mattsc> vultraz: that gives me an error while compiling
20160802 00:26:04< iceiceice> i guess i should look at what some other libs do
20160802 00:26:34< mattsc> “utility:259:9: error: implicit instantiation of undefined template 'std::__1::array<std::__1::function<bool (unsigned int, unsigned int)>, 2>’”
20160802 00:27:28< celmin> mattsc: Add #include <array> to the relevant header file.
20160802 00:27:33< celmin> vultraz: What file is it?
20160802 00:28:43< vultraz> celmin: is what?
20160802 00:29:08< vultraz> mattsc: what celmin said, and please commit any additions
20160802 00:29:11< vultraz> header-wise, that is
20160802 00:29:22< celmin> vultraz: The file where you changed vector to array
20160802 00:29:34< vultraz> many
20160802 00:29:41< celmin> ...
20160802 00:29:50< mattsc> added that to listbox.hpp
20160802 00:29:54< mattsc> compiling …
20160802 00:30:32< vultraz> mattsc: might be better to add it in generator.hpp
20160802 00:30:42< vultraz> that's where the typdef (well, using) is after all
20160802 00:31:14< mattsc> vultraz: okay; I have no idea what I am doing though, so ...
20160802 00:31:19< mattsc> well, it failed again anyway
20160802 00:31:26< mattsc> trying generator.hpp ...
20160802 00:32:36< celmin> BTW mattsc, if you could add the recall list dialog (cpp and hpp) to the XCode project while you're at this, that'd be helpful.
20160802 00:32:46< celmin> Preferably at sorted location.
20160802 00:32:49< vultraz> src/gui/dialogs/unit_recall.*pp
20160802 00:32:55< vultraz> is the path
20160802 00:33:06< celmin> (You can right-click the group and sort it if you want.)
20160802 00:33:31< celmin> Normally I'd do it, but I'm on a branch right now.
20160802 00:33:53< mattsc> vultraz, celmin: build failed again ...
20160802 00:34:00< vultraz> oh come on :/
20160802 00:34:07< vultraz> same error?
20160802 00:34:09< mattsc> this time it’s a linker error
20160802 00:34:18< vultraz> oh
20160802 00:34:18< celmin> mattsc: It's probably the files, like I said.
20160802 00:34:23< vultraz> yeah
20160802 00:34:26< vultraz> add those files above
20160802 00:34:29< mattsc> lemme try
20160802 00:34:46< mattsc> and do the include ?
20160802 00:34:55< vultraz> yes
20160802 00:36:34< mattsc> celmin: they are already in the project
20160802 00:36:55< celmin> src/gui/dialogs/unit_recall.*?
20160802 00:37:02< vultraz> can't be 
20160802 00:37:06< vultraz> I just added them hours ago
20160802 00:37:16< mattsc> oh, you said recall list dialog ...
20160802 00:37:29< mattsc> so I found recall_list_manager.*
20160802 00:37:33< celmin> Also if you see any red files, feel free to delete them.
20160802 00:37:43< vultraz> no no, not recall_list_manager 
20160802 00:39:01< mattsc> compiling again ...
20160802 00:39:07< mattsc> build failed
20160802 00:39:19< vultraz> D:
20160802 00:39:21< vultraz> what now
20160802 00:39:45< mattsc> tons of boost-related errors in unit_recall*
20160802 00:40:13< vultraz> what
20160802 00:40:14< celmin> Example?
20160802 00:40:20< mattsc> wesnoth/src/gui/dialogs/unit_recall.cpp:128:10: error: no matching function for call to object of type 'const std::__1::__bind<std::__1::basic_string<char> (*)(boost::intrusive_ptr<const unit>, const t_string &(unit::*)() const), boost::arg<1> &, const t_string &(unit::*)() const>'
20160802 00:40:21< mattsc>                 return filter_on((*recall_list_)[i1]) < filter_on((*recall_list_)[i2]);
20160802 00:40:39-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 00:40:40< travis-ci> wesnoth/wesnoth#10054 (master - 7c45df4 : Charles Dang): The build is still failing.
20160802 00:40:40< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149053098
20160802 00:40:40-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 00:40:42< vultraz> :|
20160802 00:40:44< vultraz> :| :| :|
20160802 00:40:49< vultraz> grrrrrr
20160802 00:40:53< celmin> Hmm.
20160802 00:41:09< vultraz> why the hell does it work for me and not you
20160802 00:41:24< celmin> What exactly is this error...
20160802 00:41:50< mattsc> because you have special powers?  ;)
20160802 00:42:14< vultraz> and now travis is spewing more unrelated crap D:
20160802 00:42:16< mattsc> anyways, sorry guys, but I have to be off again
20160802 00:42:22< vultraz> alright
20160802 00:42:25< vultraz> np
20160802 00:42:44< vultraz> src/gui/dialogs/unit_recall.cpp:253:23: error: aggregate ‘gui2::generator_sort_array order_funcs’ has incomplete type and cannot be defined
20160802 00:42:45< mattsc> vultraz: I’ll test your fix to the create unit dialog once I’ve figured out how to compile
20160802 00:42:47< vultraz> whyy travis why
20160802 00:43:04< mattsc> ttyl and thanks
20160802 00:43:30< celmin> vultraz: I bet that one's the missing <array> include.
20160802 00:44:15< vultraz> does it need the include in the file?
20160802 00:44:41< vultraz> or is indirect file
20160802 00:44:43< vultraz> fine
20160802 00:45:06< celmin> generator.hpp, right?
20160802 00:45:16< vultraz> yes
20160802 00:48:52< vultraz> should i commit the include there?
20160802 00:50:11< celmin> Sure.
20160802 00:50:38< irker738> wesnoth: Charles Dang wesnoth:master 69bb5a155b7e / src/gui/widgets/generator.hpp: Attempt to appease travis https://github.com/wesnoth/wesnoth/commit/69bb5a155b7ebb888b094e6c8df51380939df24a
20160802 00:52:16< vultraz> the unit list dialog should be pretty simple to convert to gui2
20160802 00:52:21< vultraz> just a list with formatting
20160802 00:52:26< vultraz> no images, even
20160802 00:53:25< vultraz> oh, and I discovered a weird bug
20160802 00:53:46< vultraz> you can scroll to invisible options
20160802 00:53:49< vultraz> in a listbox
20160802 00:53:54< vultraz> if certain ones are filtered out
20160802 01:01:19-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160802 01:01:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 01:06:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160802 01:06:54< irker738> wesnoth: Charles Dang wesnoth:master 7332dafd75fd / src/gui/widgets/generator.cpp: Add visibility checks to up/left arrow handling https://github.com/wesnoth/wesnoth/commit/7332dafd75fd8ebb5b30d844b72d8539986d5521
20160802 01:07:07< vultraz> that was simple
20160802 01:16:58< celmin> So abilities...
20160802 01:17:13-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160802 01:17:37< vultraz> what are you doing, exactly
20160802 01:18:06< celmin> I want to be able to specify a unit's abilities using eg abilities=cures
20160802 01:18:10< celmin> With a comma-separated list.
20160802 01:18:17-!- gfgtdf_ [~chatzilla@x4e368871.dyn.telefonica.de] has joined #wesnoth-dev
20160802 01:18:20< celmin> But, I have to still support the old way as well.
20160802 01:19:10< celmin> Maybe it can be phased out eventually (not sure), but for 1.14 at least it needs to be supported.
20160802 01:20:03-!- gfgtdf [~chatzilla@x4e36342f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20160802 01:20:11-!- gfgtdf_ is now known as gfgtdf
20160802 01:21:05-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 01:21:06< travis-ci> wesnoth/wesnoth#10055 (master - 69bb5a1 : Charles Dang): The build is still failing.
20160802 01:21:06< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149059075
20160802 01:21:06-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 01:22:59< vultraz> "User message: Window not defined in WML: 'unit_recall'. Perhaps a mismatch between data and source versions. Try --data-dir <trunk-dir>
20160802 01:23:00< vultraz> Dev message: Condition 'window_types.find(*itor) != window_types.end()' failed at src/gui/widgets/settings.cpp:374 in function 'read'."
20160802 01:23:02< vultraz> :|
20160802 01:23:03< vultraz> what
20160802 01:23:35< vultraz> ohhhhh
20160802 01:23:36< vultraz> ahahaah
20160802 01:23:38< vultraz> lmfao
20160802 01:24:07 * vultraz facepalms
20160802 01:24:12< irker738> wesnoth: Charles Dang wesnoth:master 853cbb734725 / data/gui/window/unit_recall.cfg: Forgot to add Recall dialog WML... https://github.com/wesnoth/wesnoth/commit/853cbb7347254e5003b64828ed8dbe537bb21b22
20160802 01:30:02< celmin> . . .
20160802 01:30:48< celmin> Okay, I'm thinking that the only way for it to work is to separately iterate abilities added by [unit][abilities]
20160802 01:45:21-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 01:45:22< travis-ci> wesnoth/wesnoth#10056 (master - 7332daf : Charles Dang): The build is still failing.
20160802 01:45:22< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149061360
20160802 01:45:22-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 01:46:58< celmin> Okay, so [unit][abilities] (and also [unit][attacks]) is undocumented.
20160802 01:47:16< celmin> I wonder why it's even supported then.
20160802 01:47:32< celmin> Maybe something to do with modifications.
20160802 01:48:52< celmin> Like, for save files.
20160802 01:49:45< celmin> …though, simply removing it would break modifications with no_add that affect abilities.
20160802 01:50:43< celmin> What's the use case for no_add?
20160802 01:51:18< vultraz> no_add?
20160802 01:51:24< celmin> Uhh.
20160802 01:51:30< celmin> [object]no_write or sometihng
20160802 01:51:33< celmin> something
20160802 01:51:44< vultraz> doesn't write to the unit config
20160802 01:52:14< vultraz> specifically does not add a [modifications] [object] entry
20160802 01:53:21-!- gfgtdf [~chatzilla@x4e368871.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160802 01:56:50< celmin> I know what it does.
20160802 01:57:05< celmin> I'm asking for the use-case.
20160802 01:57:11< celmin> Why is this behaviour needed?
20160802 01:57:40< vultraz> well
20160802 01:57:44< vultraz> i added it for my campaign
20160802 01:57:56< vultraz> my inventory system relied on applying and removing [object]s
20160802 01:58:08< vultraz> causing a new config entry to be added every time
20160802 01:58:11< vultraz> bloating the savefile
20160802 01:58:18< celmin> Config entry?
20160802 01:58:46< vultraz>  [modifications] [object]
20160802 01:59:01< celmin> But you said you remove them too.
20160802 01:59:16< celmin> So logically, no_add is not the right choice here?
20160802 01:59:21< vultraz> I used a custom [remove_object] tag
20160802 01:59:46< celmin> If you want to remove a modification, then you shouldn't use no_add, surely?
20160802 02:00:14< vultraz> I had to manually specify the removal effect
20160802 02:00:35< celmin> So you're saying you "removed" them by applying a modification that undoes the effect?
20160802 02:00:41< vultraz> basically
20160802 02:00:42< vultraz> yes
20160802 02:00:44< celmin> I'm pretty sure that's not generically possible.
20160802 02:00:47< celmin> Because of percentages.
20160802 02:01:01< celmin> Well, okay, you could probably work out the math for that and get it to work, but it's not easy.
20160802 02:01:23< celmin> Anyway, the right approach in my opinion would be to remove the object, rather than applying a reverse object.
20160802 02:01:40< vultraz> https://github.com/8573/wesnoth-lp8/blob/master/8680s_Lua_Pack/docs/modifications.md
20160802 02:01:57< vultraz> you can easily strip an object from a unit config, but that doesn't reverse its effect
20160802 02:02:02< celmin> Objects with duration=turn and such already are removed like that, right?
20160802 02:02:11< vultraz> don't think so
20160802 02:02:21< celmin> Pretty sure they are...
20160802 02:02:43< vultraz> I think a copy of the unit is saved
20160802 02:03:01< celmin> Uhh… that sounds extremely unlikely.
20160802 02:03:30< celmin> BTW, removing the object from [modifications] should reverse its effect if the unit is rebuilt, I believe.
20160802 02:03:52< celmin> I would've expected unstore_unit to do that, but if not, transform_unit should.
20160802 02:04:12< vultraz> honestly, our whole modifications system is weird
20160802 02:04:25< celmin> Why? I think it's actually quite nice.
20160802 02:04:29< celmin> What's weird about it?
20160802 02:04:31< vultraz> you can modify a unit directly with [modify_unit], or use [object]...
20160802 02:04:51-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160802 02:05:00< celmin> Changes made with [modify_unit] are lost when the unit is rebuilt, though.
20160802 02:05:08< celmin> While changes in [modifications] persist.
20160802 02:05:15< vultraz> I see
20160802 02:05:31< vultraz> well, if you want to add a remove_object tag
20160802 02:05:34< vultraz> to mainline
20160802 02:05:37< vultraz> that would be amazing
20160802 02:05:56< celmin> I think I might do that.
20160802 02:06:12< celmin> I kinda want to remove no_write, actually.
20160802 02:06:46< celmin> It effectively seems to make [object] behave like [modify_unit].
20160802 02:07:52< celmin> (Though effects are perhaps more convenient for certain types of changes than modify_unit.)
20160802 02:07:59< vultraz> why not this
20160802 02:08:10< celmin> (But what about making [modify_unit] read effects?)
20160802 02:08:22< vultraz> add an [apply_modifications] or [modify_unit_persistent] ActionWML tag
20160802 02:08:26< vultraz> have [object] call that
20160802 02:08:51< celmin> Eh, I dunno.
20160802 02:08:58< vultraz> then it'd be clear chat is persistent
20160802 02:09:07< celmin> Chat?
20160802 02:09:16< vultraz> what*
20160802 02:09:46< celmin> Mind you, changes made with [modify_unit] should still be present after loading a saved game.
20160802 02:09:53< celmin> (Pretty sure they are.)
20160802 02:10:02< celmin> (And it should stay that way.)
20160802 02:10:18< vultraz> right
20160802 02:10:20< celmin> (Often modify_unit is actually used for transient properties like current moves, hp, xp, etc.)
20160802 02:10:28< vultraz> right
20160802 02:10:36< vultraz> and object for more permanent ones
20160802 02:11:22< celmin> Or removable ones, with duration=turn or duration=scenario.
20160802 02:12:04< vultraz> yes
20160802 02:12:27< celmin> Hmm. I guess maybe I should put the abilities refactor on hold for now. Add [remove_object] and support [modify_unit][effect].
20160802 02:12:53< vultraz> is [modify_unit] [abilities] allowed?
20160802 02:12:56< vultraz> or abilities=?
20160802 02:13:02< celmin> The latter, no.
20160802 02:13:07< celmin> The former, not sure, but probably.
20160802 02:13:33< vultraz> but then if I do that and my unit levels up, do they lose the ability
20160802 02:13:36< celmin> Though it may not behave quite as you'd expect.
20160802 02:13:38< celmin> Yes.
20160802 02:13:41< celmin> Presumably.
20160802 02:13:44< vultraz> if they do, i need to use object
20160802 02:13:59< celmin> Yes, for your use-case I think object makes the most sense.
20160802 02:14:34< vultraz> but then it bloats the unit config
20160802 02:14:48< vultraz> the more i 'equip' and 'unequip'
20160802 02:14:53< celmin> How many items do you expect people to have equipped at any one time?
20160802 02:15:06< vultraz> uh
20160802 02:15:08< vultraz> not sure
20160802 02:15:10< vultraz> just a few
20160802 02:15:28< celmin> Then it shouldn't bloat it too much if you actually remove the unequipped items, rather than reversing them.
20160802 02:15:34< vultraz> i actually keep their data in [unit] [variables] [item] 
20160802 02:16:21< celmin> And properly remove unequipped ones?
20160802 02:16:58< vultraz> that's the data for the items you carry
20160802 02:17:00< vultraz> equipped or not
20160802 02:17:12< vultraz> actually, looking at my code i wonder if im not doing things the wrong way
20160802 02:17:20< vultraz> it's been awhile since i worked on this..
20160802 02:18:23< vultraz> ok, so here's an example..
20160802 02:18:25< vultraz> http://pastebin.com/hrdTZiFA
20160802 02:18:40< vultraz> (note that this [remove_object] is basically a config strip function)
20160802 02:19:23< vultraz> if you equip it ([command]) you get a new object with a new ability
20160802 02:19:42< vultraz> unequip it ([removal_command]) you get a new object with an effect to remove that ability
20160802 02:19:56< celmin> Seems weird that you call [object] before [remove_object]...
20160802 02:19:56< vultraz> both objects are now serialized and there is no ability
20160802 02:20:09< vultraz> because see
20160802 02:20:14< vultraz> you need a new object
20160802 02:20:22< vultraz> to reverse the effect of the other object
20160802 02:20:23< vultraz> :/
20160802 02:20:31< celmin> Oh wait, in theory that remove_object should remove both of them, right?
20160802 02:20:38< vultraz> yes
20160802 02:20:47< vultraz> because the entire contents of the tag are written to the unit config
20160802 02:20:53< vultraz> I can inject a meaningless key
20160802 02:21:01< vultraz> in this case, removal_id=regen_necklace_s6
20160802 02:21:05< celmin> BTW, what happens if a troll equips and the unequips this?
20160802 02:21:07< vultraz> and filter on it
20160802 02:21:25< vultraz> the remove_object sees two [object] tags with that key and strips them
20160802 02:21:29< celmin> It probably loses the regenerates ability until it levels up, right?
20160802 02:21:31< vultraz> no idea, actually, never tried
20160802 02:21:41< vultraz> anyway, now you see the intended usecase of no_write
20160802 02:21:51< celmin> Hmm.
20160802 02:22:31< vultraz> or there's this
20160802 02:22:33< vultraz> http://pastebin.com/DzZSnQ3s
20160802 02:22:51< vultraz> as you can see, equipping the weapon or unquipping it just removes/adds an attack
20160802 02:22:55< vultraz> unequipping 
20160802 02:23:07< vultraz> i need [object] for that
20160802 02:23:11< vultraz> and then i strip it out
20160802 02:23:24< vultraz> but since you say without the object in the config it's not persistent...
20160802 02:23:41< vultraz> this is what I mean when I say the modifications system is bonkers
20160802 02:23:44< vultraz> :/
20160802 02:24:05< celmin> I don't see how this makes it "bonkers".
20160802 02:24:07< vultraz> s/just removes/adds an attack / just adds/removes/ an attack
20160802 02:24:45< vultraz> celmin: because one shouldn't need to add more bloat to the unit config just to remove or add something like this
20160802 02:24:51< vultraz> that's why I added no_write
20160802 02:24:59< vultraz> but do feel free to remove it if you can improve the system
20160802 02:25:05< celmin> I think you're somehow aproaching the whole thing wrong.
20160802 02:25:23< vultraz> i mean
20160802 02:25:32< vultraz> if we had prototypes this wouldn't be a problem
20160802 02:25:35< celmin> I think it should be possible to make it work with just this code: http://pastebin.com/GcQzzyNk
20160802 02:25:50< vultraz> celmin: no
20160802 02:25:53< vultraz> see
20160802 02:25:55< celmin> I want to somehow introduce a prototype-based system.
20160802 02:26:01< vultraz>                     [effect]
20160802 02:26:03< vultraz>                         apply_to=new_ability
20160802 02:26:04< vultraz>                         [abilities]
20160802 02:26:06< vultraz>                             {ABILITY_REGENERATES}
20160802 02:26:07< vultraz>                         [/abilities]
20160802 02:26:09< vultraz>                     [/effect]
20160802 02:26:12< vultraz> literally adds a new [ability] tag in the unit config
20160802 02:26:17< celmin> I know.
20160802 02:26:20< vultraz> so because of remove_object's implementation
20160802 02:26:26< vultraz> actually, there is a bug in it
20160802 02:26:43< celmin> I was assuming a different implementation of remove_object for that paste.
20160802 02:26:46< vultraz> (it tries to intelligently reverse effects, but it doesn't work with abilities)
20160802 02:27:08< vultraz> with that it just strips the [object] from the config and leaves the [ability]
20160802 02:27:09< vultraz> see?
20160802 02:27:12< celmin> Yes.
20160802 02:27:22< vultraz> if you can introduce a proper remove_object tag
20160802 02:27:29< vultraz> that reversed the effects of an ojbect
20160802 02:27:34< vultraz> reverses
20160802 02:27:37< vultraz> and strips it out
20160802 02:27:39< vultraz> please, please do
20160802 02:27:41< celmin> But what happens if, after stripping the object, you [transform_unit] to its current type?
20160802 02:27:50< vultraz> i dont know
20160802 02:27:52< vultraz> i haven't tried
20160802 02:27:56< celmin> Pretty sure transform_unit calls u.advance_to...
20160802 02:27:57< vultraz> this was all in 1.12 anyway
20160802 02:28:40< vultraz> anyway that's the background
20160802 02:28:45< celmin> That code you pasted is for 1.12?
20160802 02:28:52< vultraz> yes
20160802 02:29:02 * celmin switching computers again
20160802 02:29:03-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160802 02:30:03< celticminstrel> Hard to code over VNC on a smaller monitor.
20160802 02:30:28< celticminstrel> Okay, so, I'll put abilities refactor on hold for a bit.
20160802 02:30:49< vultraz> implementing proper object removal would be a huge asset for umc creators
20160802 02:34:16< vultraz> if you do that feel free to remove no_write
20160802 02:37:59< celticminstrel> I'm pretty sure that calling transform_unit with the unit's current type would have stripped out those extra ability tags, though I'm not 100% certain.
20160802 02:38:13< celticminstrel> It should work that way, certainly.
20160802 02:45:18< irker738> wesnoth: Celtic Minstrel wesnoth:master 6c01f69914a6 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update XCode project https://github.com/wesnoth/wesnoth/commit/6c01f69914a6bd40183f1a3c71cb7361715cf8ef
20160802 02:48:11< mattsc> celticminstrel: thanks — but it’s still failing for me  :(
20160802 02:48:36< celticminstrel> So what's the latest problem?
20160802 02:48:44< mattsc> same as before
20160802 02:48:49< celticminstrel> I forgot.
20160802 02:48:55< celticminstrel> Link error or something?
20160802 02:49:03< celticminstrel> Or wait, Boost problems.
20160802 02:49:20< mattsc> hold on, paste-binning …
20160802 02:49:55< mattsc> http://pastebin.com/4P2ac0L9
20160802 02:50:35< mattsc> There’s another 6 of those also, but they look the same.
20160802 02:53:56< celticminstrel> vultraz: My changelog entry says it'll be removed "in the next release". This should be read as if the changelog were for 1.13.6.
20160802 02:59:22-!- travis-ci [~travis-ci@ec2-54-163-63-103.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 02:59:23< travis-ci> wesnoth/wesnoth#10059 (master - 853cbb7 : Charles Dang): The build was fixed.
20160802 02:59:23< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149063927
20160802 02:59:23-!- travis-ci [~travis-ci@ec2-54-163-63-103.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 03:13:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160802 03:13:53-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160802 03:14:46< celticminstrel> I'm trying to figure out the error, BTW. I'm also getting similar errors myself.
20160802 03:26:36< celticminstrel> Okay, so by replacing the lambdas with binds, I seem to get errors more similar to mattsc's...
20160802 03:26:57< celticminstrel> Oh, that's because I didn't include <type_traits>, whoops. Looks like this might work then?
20160802 03:31:42 * celticminstrel tries using decltype instead.
20160802 03:33:21< celticminstrel> Ugh, this is going to make it rather uglier...
20160802 03:35:34< celticminstrel> Nope, still doesn't work. :(
20160802 03:37:32-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20160802 03:38:59 * celticminstrel blinks.
20160802 03:39:31< celticminstrel> Can the fix really be that simple?
20160802 03:39:43< celticminstrel> It is.
20160802 03:39:54< celticminstrel> All I did was capture filter_on by reference instead of by copy.
20160802 03:40:08< celticminstrel> And now it's linking.
20160802 03:43:17< celticminstrel> mattsc: Let me know if this also fixes your errors.
20160802 03:43:36< irker738> wesnoth: Celtic Minstrel wesnoth:master 7e6a1892bba0 / src/gui/dialogs/unit_recall.cpp: Fix OSX compile errors https://github.com/wesnoth/wesnoth/commit/7e6a1892bba0db68081a97614bf4cb05e47b1709
20160802 03:46:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160802 03:47:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160802 03:47:37< mattsc> celticminstrel: the previous errors are gone, but now I am getting duplicate symbol errors when linking: http://pastebin.com/kqra7a86
20160802 03:47:42< mattsc> should I try a clean build?
20160802 03:49:10< celticminstrel> That's weird...
20160802 03:49:22< celticminstrel> You could try a clean build.
20160802 03:49:33< mattsc> okay, that will take a few minutes
20160802 03:50:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160802 03:50:38-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160802 03:55:36-!- stikonas_ is now known as stikonas
20160802 03:57:51< celticminstrel> Preferences sidebar has a horizontal scrollbar even on 100% font scaling.
20160802 03:57:54< celticminstrel> 800x600
20160802 04:00:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160802 04:02:24< irker738> wesnoth: Celtic Minstrel wesnoth:master 6dab777f6623 / / (4 files in 3 dirs): Accept [effect] in [modify_unit] https://github.com/wesnoth/wesnoth/commit/6dab777f6623abe95c211fec9ba84465c63b9bfb
20160802 04:05:31< mattsc> celticminstrel: nope, same error, unfortunately
20160802 04:05:40< celticminstrel> :/
20160802 04:06:30< celticminstrel> Do you have unstaged changes in the XCode project file? Maybe the unit recall dialog has been added twice somehow.
20160802 04:06:44< mattsc> ah, crap …
20160802 04:07:26< mattsc> Have I ever mentioned that I have no idea what I am doing?  :P
20160802 04:07:43< mattsc> Yep, working now.  Thanks, celticminstrel.
20160802 04:07:48< celticminstrel> Yay!
20160802 04:14:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 04:18:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160802 04:24:40-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160802 04:25:58-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160802 04:28:07-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Client Quit]
20160802 04:31:27-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160802 04:47:10 * celticminstrel has a working [remove_object] - gave a shaman ambush, and it removed it correctly.
20160802 04:47:59< celticminstrel> I think this could actually be implemented in 1.12 with the caveat that the reversal only takes effect whenever duration=turn is processed.
20160802 04:48:34< celticminstrel> (Store the unit, set matching object's to have duration=turn, unstore the unit.)
20160802 04:48:39< celticminstrel> ^objects
20160802 04:48:45< celticminstrel> Anyway, the point is, it works.
20160802 04:49:04< celticminstrel> And was pretty easy to implement besides, given that the expire_modifications function already existed.
20160802 04:53:29< irker738> wesnoth: Celtic Minstrel wesnoth:master 53828a01b9c0 / / (4 files in 4 dirs): New [remove_object] WML tag https://github.com/wesnoth/wesnoth/commit/53828a01b9c045617933ac606342814a398cc46b
20160802 04:54:35< celticminstrel> If anyone wants to test it more extensively, feel free, but given that it uses the same mechanism for expiring modifications as duration=scenario|turn, any bugs it has would have already been bugs with object duration.
20160802 04:54:49< celticminstrel> Or bugs shared by [filter_wml] I guess.
20160802 04:59:55-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160802 05:05:25-!- JyrkiVesterinen [~JyrkiVest@87-100-219-93.bb.dnainternet.fi] has joined #wesnoth-dev
20160802 05:08:29-!- travis-ci [~travis-ci@ec2-54-144-33-251.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 05:08:30< travis-ci> wesnoth/wesnoth#10064 (master - 6c01f69 : Celtic Minstrel): The build was fixed.
20160802 05:08:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149073463
20160802 05:08:31-!- travis-ci [~travis-ci@ec2-54-144-33-251.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 05:08:45< celticminstrel> Huh? It was broken?
20160802 05:09:54< celticminstrel> That's just the Update XCode project commit. It's impossible that that commit fixed Travis.
20160802 05:28:04< celticminstrel> There could be some debate on the exact syntax of [remove_object], I guess.
20160802 05:28:27< celticminstrel> In particular, the [remove_object] tag currently is much less flexible than the underlying wesnoth.remove_modifications function.
20160802 05:29:16< celticminstrel> I won't object if anyone decides to arbitrarily change the syntax, but please at least update the wiki if you do: https://wiki.wesnoth.org/DirectActionsWML#.5Bremove_object.5D
20160802 05:29:22-!- iwaim__ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has quit [Ping timeout: 250 seconds]
20160802 05:31:46-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160802 05:31:54-!- iwaim__ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has joined #wesnoth-dev
20160802 05:32:40-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160802 05:34:04-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 05:34:05< travis-ci> wesnoth/wesnoth#10065 (master - 7e6a189 : Celtic Minstrel): The build has errored.
20160802 05:34:05< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149079787
20160802 05:34:05-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 05:34:37-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20160802 05:34:37-!- wedge010 is now known as wedge009
20160802 05:59:40< JyrkiVesterinen> 20160801 22:17:21< celticminstrel> (It's kind of crazy how many constructors are a list of blah() blah() blah() useless lines.)
20160802 05:59:53< JyrkiVesterinen> Oh. I thought it was the coding style in this project.
20160802 06:00:14< JyrkiVesterinen> I have even been careful to add new local variables to initializer lists when I have created them.
20160802 06:00:25< JyrkiVesterinen> E.g. https://github.com/wesnoth/wesnoth/commit/56e2a733e50e70d0132d4310c3363132d5c3298f#diff-c354fbc5f1702f285af47f2320fc292b
20160802 06:01:45< JyrkiVesterinen> s/local/member/
20160802 06:03:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 06:07:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 258 seconds]
20160802 06:11:52-!- fabi [~fabi@176.4.89.68] has joined #wesnoth-dev
20160802 06:36:51-!- Kwandulin [~Miranda@p200300760F60621EC175075870C55BC1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160802 06:41:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 244 seconds]
20160802 07:00:52-!- atarocch [~atarocch@194.127.9.108] has joined #wesnoth-dev
20160802 07:02:55< irker738> wesnoth: Jyrki Vesterinen wesnoth:master d76a79952317 / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Update Visual Studio project https://github.com/wesnoth/wesnoth/commit/d76a799523179e4a7faafcd3cc1fef6f18f23389
20160802 07:05:53< irker738> wesnoth: Jyrki Vesterinen wesnoth:master 3355e5bd7a8e / players_changelog: Fixes in players_changelog https://github.com/wesnoth/wesnoth/commit/3355e5bd7a8eab3850799d294e56a45376e54ed0
20160802 07:19:19-!- molt [~molt@37.122.170.190] has joined #wesnoth-dev
20160802 07:22:16-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has joined #wesnoth-dev
20160802 07:24:19-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160802 07:51:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 07:55:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160802 08:06:32-!- zookeeper_ [~lmsnie@37.35.27.57] has joined #wesnoth-dev
20160802 08:09:20-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 265 seconds]
20160802 08:15:53-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160802 08:17:04-!- Aginor [~andreas@unaffiliated/aginor] has quit [Ping timeout: 250 seconds]
20160802 08:17:12-!- Aginor [~andreas@unaffiliated/aginor] has joined #wesnoth-dev
20160802 08:17:37< VultCave> JyrkiVesterinen: wait, one does not need to have all local variable in initializer lists? o_O 
20160802 08:18:24< JyrkiVesterinen> I was talking about *member* variables. Accidentally used a wrong word.
20160802 08:18:45-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 258 seconds]
20160802 08:18:46-!- VultCave is now known as vultraz
20160802 08:18:51< JyrkiVesterinen> And yes, mentioning the variable in initializer list is optional if you're happy with default-initialization.
20160802 08:19:11< vultraz> :|
20160802 08:19:18< vultraz> well now I feel stupid
20160802 08:19:28< vultraz> I always assumed it was a thing that needed to be done
20160802 08:19:54-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160802 08:19:54-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160802 08:20:15< JyrkiVesterinen> Okay... That explains why initializer lists were faithfully initializing every single member variable.
20160802 08:20:28-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 08:20:29< travis-ci> wesnoth/wesnoth#10071 (master - d76a799 : Jyrki Vesterinen): The build has errored.
20160802 08:20:29< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149102842
20160802 08:20:29-!- travis-ci [~travis-ci@ec2-54-159-66-100.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 08:20:41< JyrkiVesterinen> And I probably wasn't the only programmer who assumed that it's just the Wesnoth coding style.
20160802 08:20:43< vultraz> I guess it's what happens when you only have wesnoth as a reference
20160802 08:31:51-!- Bonobo [~Bonobo@2001:44b8:254:3200:6830:3bc5:2e29:c8b3] has joined #wesnoth-dev
20160802 08:36:11-!- zookeeper_ is now known as zookeeper
20160802 08:36:12-!- zookeeper [~lmsnie@37.35.27.57] has quit [Changing host]
20160802 08:36:12-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160802 08:51:53-!- Kwandulin [~Miranda@p200300760F60621EC175075870C55BC1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160802 08:55:00-!- molt [~molt@37.122.170.190] has quit [Quit: Leaving]
20160802 08:59:03< loonycyborg> vultraz: JyrkiVesterinen: iirc some tool mordante was running on the code was initializing all members
20160802 08:59:06< shadowm> mordante used to require and enforce full initializer lists.
20160802 08:59:09< shadowm> Derp.
20160802 08:59:42< shadowm> The tool itself (cppcheck) does not do anything other than issue warnings against code.
20160802 09:00:27-!- Duthlet [~Duthlet@dslb-178-005-055-087.178.005.pools.vodafone-ip.de] has joined #wesnoth-dev
20160802 09:00:38< vultraz> I vaguely recall something about this
20160802 09:00:46< vultraz> Why was this?
20160802 09:04:05< vultraz> simply to satisfy the tool?
20160802 09:04:45< shadowm> Probably not, since if my memory serves you can disable and enable as many warnings as you wish, just like with real cmpilers.
20160802 09:06:42< shadowm> Oh, you probably were expecting a more precise answer. Let me fetch my phone and give mordante a call, hopefully he's not at work.
20160802 09:07:33< shadowm> Maybe I should take this opportunity to ask him why he decided to apply that horrid ttype tnaming tconvention tto teverything the ttouched.
20160802 09:07:58< vultraz> He was odd.
20160802 09:08:52< shadowm> Personally, I'm more comfortable seeing everything in the constructors so I can quickly find out what a given member is supposed to be set to at a given point.
20160802 09:09:19< vultraz> Point
20160802 09:09:24< shadowm> As well as knowing that I did not in fact forget to initialize something that wasn't supposed to be def-initialized.
20160802 09:09:39< vultraz> But I feel so stupid for thinking that was a requirement of c++ all this time
20160802 09:10:16< shadowm> It isn't, but neither is not doing arithmetic on NULL pointers. :p
20160802 09:11:39< shadowm> There are probably a lot of quirks in the Wesnoth codebase that aren't requirements either.
20160802 09:13:11< shadowm> Can't think of anything off the top of my head though.
20160802 09:13:48< vultraz> trying to force line width to 80 chars to less?
20160802 09:14:02-!- Nobun [~nobun@host124-102-dynamic.15-87-r.retail.telecomitalia.it] has joined #wesnoth-dev
20160802 09:14:07-!- Nobun [~nobun@host124-102-dynamic.15-87-r.retail.telecomitalia.it] has quit [Client Quit]
20160802 09:14:11< shadowm> That'd be completely tangential since it's formatting, not syntax.
20160802 09:14:53< shadowm> And for reference, the larger your monitor is, the more eye-unfriendly overlong lines become.
20160802 09:15:09< vultraz> Right
20160802 09:15:19< vultraz> But mordante  took the concept to an extreme.
20160802 09:15:29< shadowm> I'm not saying anything about code, but it's worth keeping in mind when laying out user interfaces.
20160802 09:16:19< shadowm> You'll find that a 80 columns limit is actually pretty lenient as far as long-lived OSS projects go.
20160802 09:16:35< shadowm> an
20160802 09:17:47< vultraz> Oh?
20160802 09:17:56< vultraz> You means others enforce less?
20160802 09:18:11< shadowm> Defining default constructors that default-initialize all members and do nothing else isn't a requirement, for C++ or Wesnoth, yet it's a thing that's cropped up in Wesnoth from time to time.
20160802 09:18:36< shadowm> But you probably already know that it's bad style and superfluous as hell.
20160802 09:18:40< shadowm> Hopefully.
20160802 09:19:40< shadowm> That one falls under the vast array of historical issues introduced by people who don't know the language enough messing with large C++ codebases.
20160802 09:19:42< vultraz> I am guilty of that sometimes.
20160802 09:20:01< vultraz> :(
20160802 09:20:06< shadowm> I believe I may have been the originator of 75% of those cases in the past 7 years.
20160802 09:21:18< shadowm> Same goes for copy constructors that do the exact same things that the compiler-defined copy constructor would do.
20160802 09:23:01< shadowm> Though sometimes the odd one out is hard to spot (e.g. if one of the participants happens to include a plain pointer or be a reference-counted object).
20160802 09:23:56< shadowm> Also, unnamed namespace members with the static storage specifier.
20160802 09:24:51< shadowm> I've seen those crop up before, and IIRC the reason they are superfluous is basically that unnamed namespace members have a default storage that is equivalent to static storage except for a specific point that doesn't usually concern anoyne but compilers.
20160802 09:26:22-!- Kwandulin [~Miranda@p200300760F6062595D26C148A25AC730.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160802 09:27:31< shadowm> Some coders have also employed wordy constructs like this: T foo = T()
20160802 09:29:54< shadowm> It is important for numeric and pointer types (you don't want to end up using a non-deterministic garbage value), but for everything else it's not needed.
20160802 09:31:50< shadowm> Back in the day at least, that particular quirk permeated most of the sound code.
20160802 09:38:06-!- Appleman1234 [~Appleman1@KD036012029236.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20160802 09:39:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 09:43:16-!- Appleman1234 [~Appleman1@KD036012026062.au-net.ne.jp] has joined #wesnoth-dev
20160802 09:44:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160802 09:51:53-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160802 09:57:26-!- ideuler [~textual@0.213.62.94.rev.vodafone.pt] has joined #wesnoth-dev
20160802 10:05:37-!- PoignardAzur [~olivier@APuteaux-654-1-216-219.w86-217.abo.wanadoo.fr] has joined #wesnoth-dev
20160802 10:06:03-!- irker738 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160802 10:12:43-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160802 10:25:36-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160802 10:28:47< PoignardAzur> Is it just me or the current wesnoth source doesn't compile?
20160802 10:29:45< vultraz> master?
20160802 10:30:15< PoignardAzur> I get a failed assert at BOOST_STATIC_ASSERT( I == is_placeholder<T>::value );
20160802 10:30:42< vultraz> D:
20160802 10:30:46< vultraz> nuuuuuu not that again
20160802 10:31:48< PoignardAzur> Never mind, I forgot to pull
20160802 10:31:59< PoignardAzur> I'm compiling
20160802 10:32:25< PoignardAzur> And omagad why so many warnings?
20160802 10:32:33< vultraz> wha?
20160802 10:32:44< PoignardAzur> Never mind
20160802 10:32:54< PoignardAzur> Anyway, I just pulled and I still have the same error
20160802 10:33:36-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160802 10:33:46< vultraz> from whence it originating?
20160802 10:33:59-!- Bonobo [~Bonobo@2001:44b8:254:3200:6830:3bc5:2e29:c8b3] has quit [Ping timeout: 250 seconds]
20160802 10:34:27< PoignardAzur> In file included from /home/olivier/Documents/wesnoth_repo/src/gui/widgets/button.cpp:17:
20160802 10:34:30< PoignardAzur> In file included from /home/olivier/Documents/wesnoth_repo/src/gui/widgets/button.hpp:19:
20160802 10:34:33< PoignardAzur> In file included from /home/olivier/Documents/wesnoth_repo/src/gui/core/window_builder.hpp:19:
20160802 10:34:36< PoignardAzur> In file included from /home/olivier/Documents/wesnoth_repo/src/gui/widgets/grid.hpp:18:
20160802 10:34:39< PoignardAzur> In file included from /home/olivier/Documents/wesnoth_repo/src/gui/widgets/widget.hpp:18:
20160802 10:34:42< PoignardAzur> In file included from /home/olivier/Documents/wesnoth_repo/src/gui/core/event/dispatcher.hpp:25:
20160802 10:34:44-!- Bonobo [~Bonobo@2001:44b8:254:3200:d0ed:1257:3fc0:b138] has joined #wesnoth-dev
20160802 10:34:45< PoignardAzur> In file included from /home/olivier/Documents/wesnoth_repo/src/utils/functional.hpp:23:
20160802 10:34:48< PoignardAzur> In file included from /usr/include/boost/bind.hpp:22:
20160802 10:34:51< PoignardAzur> In file included from /usr/include/boost/bind/bind.hpp:29:
20160802 10:35:09< PoignardAzur> By the way, we shouldn't switch to c++11 static_assert at some point
20160802 10:35:18< PoignardAzur> should*
20160802 10:35:47 * vultraz groans
20160802 10:36:00< vultraz> the error is from within the boost code, not ours
20160802 10:36:06< vultraz> it doesn't like our use of placeholders, somehow
20160802 10:38:08< vultraz> supposedly, we need to qualify them somehow since boost/bind.hpp was being included implicitely by other boost includes
20160802 10:38:32< vultraz> though it occurs to me now it might be that very thing that's causing the problems...
20160802 10:38:35< vultraz> I have no idea, really
20160802 10:38:50< vultraz> this is a very annoying bug that doesn't happen on all versions of boost, either
20160802 10:47:20< PoignardAzur> Why not remove all references to boost/bind/bind.hpp then?
20160802 10:47:40< PoignardAzur> The code doesn't actually use boost::bind, only std::bind
20160802 10:48:41< PoignardAzur> Actually, that's even simpler than that: there's just one reference to remove, in utils/functional.hpp
20160802 10:49:12< JyrkiVesterinen> Boost also uses Boost.Bind internally. We can't really do anything about that.
20160802 10:50:38< JyrkiVesterinen> Here is earlier discussion about that: http://wesnoth.org/irclogs/2016/07/%23wesnoth-dev.2016-07-25.log
20160802 10:50:55< JyrkiVesterinen> < JyrkiVesterinen> These modules depend on Boost.Bind: function, lambda, algorithm, iostreams, phoenix, python, test, tr1, variant, gil, thread, asio, heap, msm, multi_index, statechart, signals2, graph, log, property_map, numeric~odeint.
20160802 10:51:12< JyrkiVesterinen> < JyrkiVesterinen> We use many of those, in particular Boost.Thread and Boost.Asio.
20160802 10:51:24< JyrkiVesterinen> < celmin> We're using iostreams and asio.
20160802 10:53:35-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160802 10:54:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 10:55:45< PoignardAzur> By the way, there are a lot of 'missing override keyword' warnings
20160802 10:56:53< JyrkiVesterinen> Feel free to add some and send a PR.
20160802 10:57:20< JyrkiVesterinen> Wesnoth is missing so many override specifiers that no one really wants to take the task of adding them whenever possible.
20160802 10:58:09< PoignardAzur> I'm on it
20160802 10:58:13-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160802 10:58:31< PoignardAzur> Though it might be tricky since I can't compile as-is
20160802 10:58:37-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160802 10:58:39< PoignardAzur> Are missing override specifiers really a problem, by the way?
20160802 10:58:46-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Remote host closed the connection]
20160802 10:58:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160802 10:59:08-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160802 10:59:22< JyrkiVesterinen> The specifier protects from the problem where a member function doesn't override an inherited function because of a signature mismatch.
20160802 10:59:30-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Client Quit]
20160802 10:59:51< JyrkiVesterinen> In existing code, the lack of the specifier isn't a problem because the code is fairly stable already.
20160802 11:00:03< JyrkiVesterinen> However, the override specifier should definitely be used in new code.
20160802 11:00:47< JyrkiVesterinen> In my previous job, I once fixed a bug that the override specifier would have prevented.
20160802 11:01:04< PoignardAzur> Right
20160802 11:01:42< PoignardAzur> You replace invisble errors with compile errors
20160802 11:01:49< JyrkiVesterinen> Exactly.
20160802 11:20:43< PoignardAzur> Well, I compiled without warnings up to the one boost error
20160802 11:22:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160802 11:32:43-!- Kwandulin [~Miranda@p200300760F6062595D26C148A25AC730.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160802 11:37:05-!- ideuler [~textual@0.213.62.94.rev.vodafone.pt] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
20160802 11:40:37< PoignardAzur> And, made a pull request
20160802 11:40:58< PoignardAzur> If someone compiles it and there are still warnings, could you send me a pastebin?
20160802 11:50:32-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160802 11:51:34-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160802 11:54:17-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160802 11:55:11-!- VultCave [~chatzilla@124.109.10.167] has quit [Ping timeout: 244 seconds]
20160802 12:06:11< JyrkiVesterinen> PoignardAzur: I could also add you to game credits (I see a PR of yours has already been merged).
20160802 12:06:29< JyrkiVesterinen> Would you prefer if I added your real name, or only the nick?
20160802 12:15:14-!- Kwandulin [~Miranda@p200300760F6062591855A562E88131C0.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160802 12:16:17-!- ideuler [~textual@0.213.62.94.rev.vodafone.pt] has joined #wesnoth-dev
20160802 12:18:18-!- irker333 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160802 12:18:18< irker333> wesnoth: Olivier FAURE wesnoth:master 374a315f948f / src/ (7 files in 2 dirs): Add override specifier to derived virtual methods https://github.com/wesnoth/wesnoth/commit/374a315f948ff42c8a3b3d93e713b6c1315c3d27
20160802 12:18:18< irker333> wesnoth: Jyrki Vesterinen wesnoth:master 3a77d8db53e9 / src/ (7 files in 2 dirs): Merge pull request #723 from PoignardAzur/add_override https://github.com/wesnoth/wesnoth/commit/3a77d8db53e9ca0e24780d1bfe3159666bf7bb59
20160802 12:18:51-!- Bonobo [~Bonobo@2001:44b8:254:3200:d0ed:1257:3fc0:b138] has quit [Ping timeout: 250 seconds]
20160802 12:21:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 12:25:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160802 12:36:50< PoignardAzur> JyrkiVesterinen: not sure if it's too late, but my real name + nick is fine
20160802 12:37:07< PoignardAzur> (which file is it added to?)
20160802 12:37:33< JyrkiVesterinen> It's data/core/about.cfg. I'm already adding it myself.
20160802 12:38:09< JyrkiVesterinen> (I'm making a release build to verify that it shows up and that I didn't break anything. I never push untested code.)
20160802 12:38:50< PoignardAzur> less data/core/about.cfg.
20160802 12:38:55< vultraz> you're building to test an addition to a wml file? o_O
20160802 12:39:00< PoignardAzur> crap, wrong terminal ^^
20160802 12:40:40< PoignardAzur> So, since I still can't compile, are there warnings left?
20160802 12:41:24< JyrkiVesterinen> vultraz: Yes. My "I test everything" rule doesn't have exceptions.
20160802 12:41:43< vultraz> you do realize you don't have to build to see wml changes...right?
20160802 12:41:50< JyrkiVesterinen> PoignardAzur: Can't tell. I compile with Microsoft Visual Studio, which has different warnings.
20160802 12:42:15< JyrkiVesterinen> Yes, I do realize it. Still, I'm used to rebuild whenever I need to launch Wesnoth.
20160802 12:43:29< irker333> wesnoth: Jyrki Vesterinen wesnoth:master c4d51b1bbb5f / data/core/about.cfg: Add @PoignardAzur to credits https://github.com/wesnoth/wesnoth/commit/c4d51b1bbb5f26774d30b423a2e47784353082bc
20160802 12:43:35< JyrkiVesterinen> Done.
20160802 12:43:50< JyrkiVesterinen> Thanks for your contribution, PoignardAzur. :)
20160802 12:46:42< PoignardAzur> nice
20160802 12:53:24-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160802 12:58:03-!- ideuler [~textual@0.213.62.94.rev.vodafone.pt] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
20160802 13:04:51-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160802 13:05:56-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160802 13:20:51-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160802 13:21:33-!- molt [~molt@37.122.170.190] has joined #wesnoth-dev
20160802 13:21:47< iceiceice> vultraz, JyrkiVesterinen, iirc part of the reason to initialize all members in the initializer lists is that prior to C++11 the rules were different, and sometimes you could get "default initialized" (i.e. uninitialized)  members, basically depending on whether a structure was considered POD or not by the compiler
20160802 13:22:07< iceiceice> post C++11 its simpler and this hole doesn't really exist anymore,
20160802 13:22:27< iceiceice> but in c++03 it probably does make sense to explicitly default initialize all members in the ctor IMO
20160802 13:22:55< iceiceice> there were some really obscure rules about initialization that got changed / fixed in C++11
20160802 13:28:43< iceiceice> idk if there is a reference that is at all readable, but i think this gives the idea:
20160802 13:28:43< iceiceice> http://stackoverflow.com/questions/29765961/default-value-and-zero-initialization-mess
20160802 13:31:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160802 13:33:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160802 13:35:04-!- TC02 [~quassel@venus.arosser.com] has quit [Ping timeout: 260 seconds]
20160802 13:36:41-!- Kwandulin [~Miranda@p200300760F6062591855A562E88131C0.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160802 13:38:10< iceiceice> i guess this is the right reference: http://en.cppreference.com/w/cpp/language/default_initialization
20160802 13:52:57< vultraz> blah
20160802 13:53:03< vultraz> cannot figure out why this is crashing
20160802 13:55:28-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160802 14:06:22< mattsc> vultraz: on a more positive note, your fix to the select unit dialog is working for me.  Thanks.
20160802 14:06:36< vultraz> \o/
20160802 14:16:14< PoignardAzur> So, apparently I can compile wesnoth with g++, but not with clang++
20160802 14:16:59< PoignardAzur> That's... I have no idea why
20160802 14:17:51-!- Kwandulin [~Miranda@p200300760F606259A5EBAA652DC5503C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160802 14:23:25-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160802 14:26:47< vultraz> I guess I'm passing a bad reference or pointer around somewhere...
20160802 14:30:02< vultraz> but that doesn't really make sense
20160802 14:32:23< vultraz> eh
20160802 14:32:24< vultraz> hm
20160802 14:32:31< vultraz> maybe it's something to do with these being copies?
20160802 14:32:58< vultraz> no, that doesn't make sense...
20160802 14:33:16< vultraz> unless it not using vec[i] as the caller object?
20160802 14:34:35< vultraz> celticminstrel: I'm trying to port the new sorting code to other dialogs (without generalizing it, since it needs to capture 'this' and there's no point making it a pure virtual method somewhere), and this builds, but on sort wesnoth immediately crashes. http://pastebin.com/mmnmbA1m
20160802 14:35:18< vultraz> games_[i1] etc should mean the vector object is used for the value of name and modified...shouldn't it?
20160802 14:35:30< vultraz> object at that index
20160802 14:37:58< vultraz> it's not an OOB issue since at() doesn't fix it..
20160802 14:38:05 * vultraz heads off to try to sleep
20160802 14:38:22< PoignardAzur> Stupid question, you're sure the lambda doesn't outlive this?
20160802 14:38:34< PoignardAzur> I mean, the 'this' object it captures
20160802 14:39:22< vultraz> eh?
20160802 14:39:31< vultraz> I'm not sure of anything of the sort.
20160802 14:40:53< PoignardAzur> games_[i1] is a part of the this object, right?
20160802 14:41:21< vultraz> yes
20160802 14:41:36< PoignardAzur> So if you try to evaluate the lamba after the corresponding tgame_load is destroyed,
20160802 14:41:55< PoignardAzur> it would try to access a variable that no longer exists
20160802 14:41:56< PoignardAzur> I think
20160802 14:42:01< vultraz> in this dialog, it's a vector of objects. in the other dialog, it was a shared_ptr containing a vector of pointers.
20160802 14:42:19< vultraz> PoignardAzur: but that doesn't make sense in this case, since the dialog isn't destroyed yet...
20160802 14:42:40< PoignardAzur> Try to do a assert(this), just to check?
20160802 14:42:49< JyrkiVesterinen> vultraz: Your code looks correct to me.
20160802 14:43:05< JyrkiVesterinen> The most effective way to find the cause would be to reproduce the crash under a debugger.
20160802 14:43:19< PoignardAzur> Or valgrind
20160802 14:43:19< vultraz> release build stacktrace is useless...
20160802 14:43:25< vultraz> gonna have to make a debug one
20160802 14:43:58< PoignardAzur> (also, to correct myself, assert(this) wouldn't work anyway)
20160802 14:45:12< vultraz> valgrind is black magic to me
20160802 14:50:27< PoignardAzur> vultraz: well, there are a lot of advanced functions
20160802 14:51:04< PoignardAzur> but if you want to find a segfault or obvious memory errors, there's nothing easier
20160802 14:51:48< PoignardAzur> you start in command line with valgrind as a prefix (like "valgrind wesnoth")
20160802 14:51:56< PoignardAzur> And you run until it crashes
20160802 14:57:15< celticminstrel> I guess ancestral's build isn't out yet?
20160802 14:57:19-!- JyrkiVesterinen [~JyrkiVest@87-100-219-93.bb.dnainternet.fi] has quit [Quit: Going somewhere]
20160802 15:09:11-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160802 15:09:31< vultraz> huh.. what's happening here
20160802 15:09:56< vultraz> now the recall sorting isn't working either??
20160802 15:10:02< vultraz> well let's see what the stacktrace is..
20160802 15:10:11-!- ideuler [~textual@0.213.62.94.rev.vodafone.pt] has joined #wesnoth-dev
20160802 15:11:11< PoignardAzur> Where is the client's main() function?
20160802 15:11:27< PoignardAzur> I cant find it :/
20160802 15:12:33< vultraz> wesnoth.cpp I think
20160802 15:13:57< PoignardAzur> thanks
20160802 15:18:30< vultraz> http://pastebin.com/vCu5q8mK
20160802 15:18:32< vultraz> hmmmmm
20160802 15:22:25< vultraz> celticminstrel: ok, I think there's some bad interaction here between this method and the use of an array
20160802 15:22:34< vultraz> dialogs that use the old method work fine
20160802 15:23:05< vultraz> but the question is what
20160802 15:24:29< vultraz> ideas?
20160802 15:25:30< vultraz> is foo[n] = bar not valid with arrays?
20160802 15:25:37< vultraz> wait, no, that's not it..
20160802 15:25:45< vultraz> other dialogs work fine..
20160802 15:25:47< vultraz> blah
20160802 15:25:53< vultraz> *sleep*
20160802 15:36:39-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160802 15:42:51< fabi> hi mattsc
20160802 15:43:07-!- ggeneral [~ggeneral@nat58.opti.net.ua] has joined #wesnoth-dev
20160802 15:44:17-!- irker333 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160802 15:46:02< PoignardAzur> vultraz: I think filter_on is the problem
20160802 15:46:13< PoignardAzur> It's a dangling reference
20160802 15:47:03< mattsc> hi fabi
20160802 15:47:11< celticminstrel> So try const Fnc&?
20160802 15:47:18< celticminstrel> Or something?
20160802 15:47:35< PoignardAzur> Mhh
20160802 15:47:59< PoignardAzur> std::bind returns a temporary, right?
20160802 15:48:20< PoignardAzur> So there might still be a problem
20160802 15:48:54< PoignardAzur> Or capture filter_on by copy instead of reference
20160802 15:52:24-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has quit [Ping timeout: 276 seconds]
20160802 15:57:11-!- Kwandulin [~Miranda@p200300760F606259A5EBAA652DC5503C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160802 15:58:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 16:05:32-!- PoignardAzur [~olivier@APuteaux-654-1-216-219.w86-217.abo.wanadoo.fr] has quit [Ping timeout: 240 seconds]
20160802 16:06:17-!- JyrkiVesterinen [~JyrkiVest@78-27-110-119.bb.dnainternet.fi] has joined #wesnoth-dev
20160802 16:10:11-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160802 16:11:46< JyrkiVesterinen> vultraz: I think PoignardAzur is right, and order_funcs is outliving the filter function objects generated by std::bind().
20160802 16:12:24< JyrkiVesterinen> IIRC, you weren't able to compile the game if you tried to capture the functors by value (even though it should work as far as I can see).
20160802 16:13:19< JyrkiVesterinen> One option would be to assign the functors to member variables of the dialog.
20160802 16:13:36-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160802 16:14:16< JyrkiVesterinen> Another possibility would be to just define the filter_on functions as regular functions and forget about std::bind().
20160802 16:16:36-!- ggeneral [~ggeneral@nat58.opti.net.ua] has left #wesnoth-dev []
20160802 16:22:08< celticminstrel> BTW vultraz, does the recall dialog show recall cost?
20160802 16:22:32< celticminstrel> .JyrkiVesterinen: I was the one unable to compile.
20160802 16:22:55< celticminstrel> (And mattsc)
20160802 16:23:47< celticminstrel> I guess my fix wasn't really a fix then...?
20160802 16:24:13< celticminstrel> I'll try something else.
20160802 16:24:33< celticminstrel> Maybe it'll work if I put them in a std::function
20160802 16:30:38< fabi> Is there anywhere a grammar of WML, the prepro and the formula thing?
20160802 16:34:20< celticminstrel> I feel like I wrote one up for you awhile ago.
20160802 16:35:09< celticminstrel> Though that was WML only, I guess.
20160802 16:35:31< celticminstrel> Maybe I'll do it again, this time on the wiki.
20160802 16:35:44< fabi> You wrote one for me?
20160802 16:35:58< celticminstrel> I think so? It was in a pastebin or something.
20160802 16:36:05< fabi> hmmm
20160802 16:36:10< fabi> I am getting old :-)
20160802 16:36:15< celticminstrel> But it would've expired by now.
20160802 16:36:43< celticminstrel> Of course a WML grammar would not capture the schema.
20160802 16:37:21< fabi> well, that is not much of a problem
20160802 16:38:04< celticminstrel> Speaking of schemas, the GUI2 code is already validated against them right?
20160802 16:38:09< zookeeper> celticminstrel, it was in the screenshots. it does show it.
20160802 16:38:35< celticminstrel> I wonder if it could validate other WML too.
20160802 16:38:52-!- iceiceice [~chris@nat-tvwna-outside-visitornet2-a-201.princeton.org] has joined #wesnoth-dev
20160802 16:38:54-!- iceiceice [~chris@nat-tvwna-outside-visitornet2-a-201.princeton.org] has quit [Changing host]
20160802 16:38:54-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160802 16:39:05< fabi> hi iceiceice
20160802 16:39:11< celticminstrel> Though of course that would require actually writing the schema.
20160802 16:40:00< iceiceice> hi fabi
20160802 16:41:00< fabi> celticminstrel: hmmmm, I prefer another approach. I have put the scheme of the wml tags into lua tables and check the table at run time.
20160802 16:41:35< fabi> at the same time that lua tables can be used to generate the api documentation
20160802 16:41:53< celticminstrel> I don't really get it.
20160802 16:42:10< fabi> a file containing lua code
20160802 16:42:28< fabi> it defines the function that is executed whan a wml tag is called
20160802 16:42:36< fabi> although it comes with a table containing the scheme
20160802 16:42:48< fabi> or better the function is part of the table that also contains the scheme
20160802 16:43:21< fabi> before the function is executed the argument table is validated against the scheme.
20160802 16:43:37< celticminstrel> ActionWML is indeed kinda problematic for a schema. I think you'd have to just say "any tag is allowed here".
20160802 16:43:44< celticminstrel> Same for ConditionalWML.
20160802 16:44:17< fabi> hmmm
20160802 16:44:31< celticminstrel> (Maybe you've done away with those, I dunno.)
20160802 16:44:33< iceiceice> you could just review the source code and see what the engine actually accepts
20160802 16:44:42< iceiceice> it probably changes a lot from version to version
20160802 16:44:56< iceiceice> there was a ton of legacy conditional syntax that i remember we deleted
20160802 16:47:26< fabi> Well, there our interrests fell apart. I just want to transcompile WML (assuming it already works) and get rid of it forever, not validate it.
20160802 16:47:55-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160802 16:48:36< celticminstrel> I don't think that goal is any more achievable now than I did last time it came up.
20160802 16:48:41< celticminstrel> Hi ancestral.
20160802 16:49:09< fabi> celticminstrel: Why? Do you see technical problems?
20160802 16:49:20< celticminstrel> No.
20160802 16:49:25< celticminstrel> The problems are not technical.
20160802 16:49:48< celticminstrel> Probably.
20160802 16:50:29< celticminstrel> BTW, you can't really define "one function for every WML tag". Sometimes the same tag has a different meaning in different contexts.
20160802 16:50:56< celticminstrel> For example, [if] in animations is totally different than in ActionWML or story screens.
20160802 16:51:25< iceiceice> yeah, any solution would have to be context sensitive to some extent
20160802 16:51:29< fabi> if in animations is only a table key
20160802 16:52:13< fabi> same in story screen
20160802 16:52:25< fabi> only the action wml if is really a function
20160802 16:52:49< iceiceice> fabi: i guess i could show you the parser i made before
20160802 16:52:53< iceiceice> i had to solve all of these issues
20160802 16:53:17< iceiceice> in my parser there is a struct for each wml tag, and each possible context that it could appear
20160802 16:53:23< iceiceice> so its like blazingly fast :)
20160802 16:53:24< fabi> yes please
20160802 16:53:24< iceiceice> no configs
20160802 16:53:33< iceiceice> i would have to dig out the code though
20160802 16:53:34-!- atarocch [~atarocch@194.127.9.108] has quit [Ping timeout: 258 seconds]
20160802 16:54:02< celticminstrel> iceiceice: So does that support arbitrary tags?
20160802 16:54:20< iceiceice> no, i think it only supported the tags that were legal
20160802 16:54:27< iceiceice> and i only tested it against mainline
20160802 16:54:43< celticminstrel> But what about places where any tag is legal?
20160802 16:54:45< iceiceice> actually i found some bugs in mainline by running this parser :)
20160802 16:54:51< celticminstrel> For example, in [set_variables].
20160802 16:54:57< celticminstrel> Did you fix those bugs?
20160802 16:55:00< iceiceice> i think in that case it uses something like config
20160802 16:55:06< iceiceice> i reported them to vultraz and asked him if they were actually bugs
20160802 16:55:07< celticminstrel> I se.
20160802 16:55:10< celticminstrel> ^see
20160802 16:55:15< iceiceice> and usually it was agreed that they were mistyped tag attributes or something
20160802 16:55:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160802 16:56:05< fabi> Some time ago I went through what the tool that generates the checker for the emacs wml mode collects.
20160802 16:56:21< fabi> There were dozens of misspelled tags and attributes in the code base
20160802 16:56:55-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160802 16:57:53-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160802 16:57:54-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160802 17:00:49-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Ex-Chat]
20160802 17:01:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 17:14:13-!- ideuler [~textual@0.213.62.94.rev.vodafone.pt] has quit [Quit: Chakalaka.]
20160802 17:17:37-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160802 17:31:46-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160802 17:35:09-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160802 17:35:10-!- wedge010 is now known as wedge009
20160802 17:41:16-!- gfgtdf [~chatzilla@x4e368871.dyn.telefonica.de] has joined #wesnoth-dev
20160802 17:42:11< gfgtdf> celticminstrel: no_add=yes is quiet useful sometimes, there are just some things that lua unit proxies currently cannot do such lika adding abiltites or attacks.
20160802 17:43:11< gfgtdf> celticminstrel: and [modify_unit] is just slow and unsuable in some places sicne it uses sotre+change variables+unstore internally, which is not only slow it also impes that the unit is rebuild form that config.
20160802 17:44:26< gfgtdf> celticminstrel: s for examepl when i implement custom effect with wesnoth.effects is often use some exixten in effect with use no_add=yes
20160802 17:45:23< gfgtdf> celticminstrel: the wiki example on how to use wesnoth.effects shows a same usecase for no_add=yes
20160802 17:45:45< gfgtdf> sample*
20160802 17:49:25< celticminstrel> gfgtdf: I'm pretty syre you don't need no_add=yes for that.
20160802 17:49:28< celticminstrel> ^sure
20160802 17:49:41< celticminstrel> You can call wesnoth.effect.attack(unit, cfg) or whatever.
20160802 17:49:50< celticminstrel> ^effects
20160802 17:51:02< celticminstrel> That said, while I'll probably remove no_add from the API, I may make passing an empty string as the tag type have the same effect.
20160802 17:51:27< celticminstrel> no_add causes problems for the abilities refactor, but I don't think removing it actually solves those problems.
20160802 17:52:14< celticminstrel> gfgtdf: However, do you have a use-case for [object]no_write=yes?
20160802 17:52:30< celticminstrel> Obviously it uses the same thing internally, but it's just a specific case of it.
20160802 17:53:04< celticminstrel> Maybe modify_unit could be optimized to not store the unit if there are only effect, object, trait, advancement subtags...
20160802 17:53:59< celticminstrel> (Actually, it'd probably be best if modify_unit could be made to not store the unit at all, but that'd be harder to maintain.)
20160802 17:56:11< gfgtdf> celticminstrel: hmm no i actuall never use [object], always add_modification directly.
20160802 17:57:56< gfgtdf> celticminstrel: hmm maybe you can, when i wrote that wiki code it was afaik not possible to call c++ mainline effects from lua like that.
20160802 17:58:21< celticminstrel> Yeah, it wasn't since I added that later.
20160802 17:58:49< celticminstrel> (I should also add wesnoth.conditional_wml.have_unit etc...)
20160802 17:59:00< celticminstrel> (Or conditional_actions, whichever it is.)
20160802 18:01:06< celticminstrel> BTW, I'm not getting a crash in the recall dialog with the current way the functions are done. I'll try making it std::function anyway though, maybe that'll solve it for others?
20160802 18:12:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160802 18:14:57-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160802 18:24:52< ancestral> celticminstrel: What were you saying about the pango modules? Are they not used?
20160802 18:25:34< celticminstrel> ancestral: I'm pretty sure I've gotten dyld errors with them in the past, so that would imply that they're used.
20160802 18:25:48< celticminstrel> ancestral: What I'm saying is that they shouldn't be committed to the repository.
20160802 18:25:50< ancestral> Do you know how to build them?
20160802 18:25:53< ancestral> Ah right
20160802 18:26:07< ancestral> Whenever I build pango, I don’t see those shared object modules
20160802 18:26:15< celticminstrel> I don't really know, but I would've expected them to be built as part of pango...
20160802 18:30:10< celticminstrel> Looks like MacPorts places them in /opt/local/etc/pango, for what that's worth (maybe not much).
20160802 18:30:29< celticminstrel> Ah, wait, no.
20160802 18:30:43< celticminstrel> The actual shared objects are not there...
20160802 18:31:39< celticminstrel>  /opt/local/lib/pango
20160802 18:31:54< celticminstrel> I guess I didn't have pango installed via MacPorts.
20160802 18:32:04< celticminstrel> But I did on the previous system.
20160802 18:33:48< celticminstrel> ancestral: How are you building pango?
20160802 18:33:54< ancestral> Homebrew
20160802 18:34:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 18:34:09< ancestral> Oh, let’s see
20160802 18:35:07-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160802 18:35:07< celticminstrel> What version?
20160802 18:35:14< celticminstrel> Pango, not Homebrew.
20160802 18:35:54< celticminstrel> https://github.com/Homebrew/legacy-homebrew/issues/44764
20160802 18:36:03< ancestral> I just built 1.40
20160802 18:36:07< ancestral> I built 1.38 previously
20160802 18:36:32< ancestral> Ah
20160802 18:36:35< celticminstrel> Sounds like the modules may no longer be modules? I dunno. But you should read that thread either way.
20160802 18:36:36< ancestral> So it’s not a thing anymore?
20160802 18:37:03< celticminstrel> MACOSX_DEPLOYMENT_TARGET needs to be 10.7.
20160802 18:44:03< ancestral> Is that a build setting, or a flag?
20160802 18:44:30< celticminstrel> I'm not quite sure, but the thread called it an environment variable.
20160802 18:45:03< celticminstrel> And also claimed it was impossible to set it in Homebrew...
20160802 18:45:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160802 18:48:23< celticminstrel> So, I got it to compile with std::function, but I had to manually specify the template argument.
20160802 18:48:35< celticminstrel> Which is now just the return type, not the whole function type.
20160802 18:50:37-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160802 18:57:04-!- irker523 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160802 18:57:04< irker523> wesnoth: Celtic Minstrel wesnoth:master e75eaca5a00f / src/gui/dialogs/ (unit_recall.cpp unit_recall.hpp): Attempt to fix recall dialog crashes https://github.com/wesnoth/wesnoth/commit/e75eaca5a00facc44367b7bbfcd2994846f56519
20160802 18:58:33< gfgtdf> celticminstrel: ^that look like a step backwars to me in both readability and performance, you know teh exact error why that was needed =
20160802 18:58:34< gfgtdf> ?
20160802 18:58:37< celticminstrel> vultraz (or anyone else who experienced it): Let me know if that fixes it.
20160802 18:58:57< celticminstrel> Why is it a step backwards in performance?
20160802 18:59:16< celticminstrel> For readability, I don't think it has changed. It's a little uglier but no less readable in my opinion.
20160802 18:59:38< gfgtdf> celticminstrel: becasue calling a st::function is usually slower than calling whatever bind or labdas return.
20160802 18:59:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160802 19:00:08< celticminstrel> Well, if these functions were going to be called hundreds of times in a loop, I might consider that a performance concern.
20160802 19:00:32< celticminstrel> But they're only called once in response to a mouse click (well, once per click, but still), so I doubt it'll make much difference.
20160802 19:01:08< celticminstrel> Anyway, it didn't compile on Mac without the std::function, so that's a higher concern than performance.
20160802 19:01:21< gfgtdf> celticminstrel: well sorting a vector is o(n log(n)) or o(n^2) dependign on the algorith so it is called quiet often if there are enough items in the list
20160802 19:01:28< celticminstrel> (It did compile when I passed them by reference, but apparently that breaks other platforms.)
20160802 19:01:57< celticminstrel> Oh, right, it's called as the comparator.
20160802 19:02:47< celticminstrel> Still, performance is less important than ensuring it compiles on all supported platforms/toolsets.
20160802 19:03:13< celticminstrel> If it turns out not to fix vultraz's crash, then perhaps it can be reverted.
20160802 19:03:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 19:15:57-!- gfgtdf [~chatzilla@x4e368871.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160802 19:21:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160802 19:22:07-!- atarocch [~atarocch@ipbcc2d6b3.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160802 19:27:27-!- travis-ci [~travis-ci@ec2-54-163-72-166.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 19:27:28< travis-ci> wesnoth/wesnoth#10080 (master - e75eaca : Celtic Minstrel): The build was broken.
20160802 19:27:28< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149274814
20160802 19:27:28-!- travis-ci [~travis-ci@ec2-54-163-72-166.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 19:28:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160802 19:29:18< celticminstrel> Well... that works on clang but fails on GCC, huh?
20160802 19:30:00< celticminstrel> Maybe we can just put preprocessor things to use vultraz's original way (without the & in the capture list) on GCC and the std::function way on clang.
20160802 19:31:15< celticminstrel> Or maybe just on OSX, since all the people who couldn't compile it were on OSX.
20160802 19:32:36< celticminstrel> Maybe we should ask ancestral if he can compile it.
20160802 19:33:59-!- fabi [~fabi@176.4.89.68] has quit [Ping timeout: 244 seconds]
20160802 19:36:50< celticminstrel> mattsc: What's your OSX and XCode versions?
20160802 19:38:12< vultraz> I have returned.
20160802 19:38:22< celticminstrel> See your pings
20160802 19:38:22< mattsc> 10.11.6 and 7.3.1
20160802 19:38:32< mattsc> celticminstrel: ^
20160802 19:38:50< celticminstrel> 'kay
20160802 19:39:12< celticminstrel> I wonder if any non-OSX people actually use clang.
20160802 19:39:18< vultraz> [03:22:07]	celticminstrel	BTW vultraz, does the recall dialog show recall cost? <- yes
20160802 19:39:27< celticminstrel> BTW vultraz, I was wondering if we should remove the unmaintained project files.
20160802 19:39:39< vultraz> yes
20160802 19:39:39< celticminstrel> That's CodeBlocks+scons and CodeSomethingElse.
20160802 19:39:53< celticminstrel> I think there was a more important ping than the recall cost.
20160802 19:40:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 19:40:09< vultraz> [05:58:36]	celticminstrel	vultraz (or anyone else who experienced it): Let me know if that fixes it. <- building now
20160802 19:40:34< celticminstrel> If it doesn't compile, I'll use preprocessor trickery.
20160802 19:40:51< celticminstrel> Unless it's something easily fixed.
20160802 19:40:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160802 19:41:00< vultraz> or we could revert to a vector?
20160802 19:41:15< celticminstrel> Huh?
20160802 19:41:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 19:41:40< celticminstrel> Was that really the problem?
20160802 19:41:46< vultraz> I think so.
20160802 19:41:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160802 19:41:49< vultraz> I didn't test.
20160802 19:42:01< celticminstrel> Well, I can try that.
20160802 19:42:08< vultraz> I think it was the new method combined with the array
20160802 19:42:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 19:42:43< vultraz> That is, being an array by itself isn't a problem
20160802 19:42:53< vultraz> But an array with this code is the problem
20160802 19:43:10< vultraz> At least, that's my suspicion 
20160802 19:44:29< zookeeper> Jetrel_bot, got everyone placeholdered: https://dl.dropboxusercontent.com/u/63964618/wesnoth/quenoth/placeholders.png
20160802 19:45:07< vultraz> heh
20160802 19:45:11< celticminstrel> Kinda wish they were labelled. :P
20160802 19:45:21< vultraz> Nice use of some of the faeries 
20160802 19:45:31< celticminstrel> For placeholders, they look pretty good, I'd say.
20160802 19:45:37< vultraz> ^
20160802 19:45:57< celticminstrel> The beast rider looks like an obvious hack though.
20160802 19:46:11< celticminstrel> But pretty good despite that.
20160802 19:46:21< celticminstrel> (Might be cool to have the mount as a standalone unit...)
20160802 19:46:46 * vultraz zzzZZZzz
20160802 19:46:55< vultraz> debug builds take FOREVER to build
20160802 19:46:55< celticminstrel> ...?
20160802 19:46:58< celticminstrel> Oh.
20160802 19:47:18< vultraz> I need a better computer
20160802 19:47:46< celticminstrel> Me too.
20160802 19:47:59< celticminstrel> Well okay, I could switch to Windows.
20160802 19:48:06< celticminstrel> Then I wouldn't need a better computer.
20160802 19:48:11< vultraz> Sadly we cannot write them off as work expenses with wesnoth.inc :P
20160802 19:52:21< vultraz> Crash still here
20160802 19:52:44< vultraz> testing reverting to a vector
20160802 19:53:07< celticminstrel> I'm testing reverting to a vector minus that last commit - you're testing it with that last commit?
20160802 19:53:17< celticminstrel> I guess covering both is good.
20160802 19:54:11< vultraz> yes
20160802 19:54:17< celticminstrel> If it doesn't work reverted to a vector, try without the last commit (git revert HEAD --no-commit)
20160802 19:54:25< celticminstrel> (And revert it again)
20160802 19:54:30< celticminstrel> (The vector bit)
20160802 19:54:49< celticminstrel> It's probably better for both of us to cover both rather than one of us covering each.
20160802 19:56:21< celticminstrel> Ah, wait, so you're saying it does compile with the last commit.
20160802 19:56:39< celticminstrel> That means I need to trawl through Travis's log...
20160802 19:58:32< celticminstrel> I don't get a crash myself, though I could just be trying to reproduce it wrong; but clicking the listbox headers doesn't do anything bad.
20160802 19:58:41< celticminstrel> Mind you, the recall list is one unit. I dunno if that's relevant.
20160802 19:58:54< vultraz> try with more units
20160802 19:59:01< celticminstrel> Will do.
20160802 19:59:39< vultraz> sigh. still crashing.
20160802 19:59:47< celticminstrel> Still won't compile with vector minus last commit.
20160802 20:00:20< vultraz> trying that now
20160802 20:10:45< vultraz> still crashing..
20160802 20:11:07< vultraz> I wonder..
20160802 20:11:11< celticminstrel> Guess you'll need to somehow track it down properly?
20160802 20:13:28< celticminstrel> For the record, whether it's an array or a vector doesn't affect my ability to compile, though I'd prefer leaving it as an array.
20160802 20:22:14< vultraz> i've doing a hard reset back to try to find the commit that caused this
20160802 20:22:36< vultraz> i'm*
20160802 20:26:34-!- JyrkiVesterinen [~JyrkiVest@78-27-110-119.bb.dnainternet.fi] has quit [Quit: .]
20160802 20:35:26< vultraz> yeah, something's seriously wrong
20160802 20:35:59-!- mjs-de [~mjs-de@x4db54899.dyn.telefonica.de] has joined #wesnoth-dev
20160802 20:36:00< vultraz> i reverted back all the way to the commit where i committed the gui2 recall dialog
20160802 20:36:02< vultraz> still crashes
20160802 20:36:08< vultraz> how can this be :|
20160802 20:37:10< vultraz> and the game load dialog's sort crashes still too, despite being reverted to use the old code..
20160802 20:39:20< vultraz> but it doesn't crash if I run it with the deugger??
20160802 20:39:22< vultraz> whaaa??
20160802 20:39:27< vultraz> wesnoth y u do dis!
20160802 20:45:38< vultraz> er...
20160802 20:45:58< vultraz> oh, I think I'm using the wrong executable here
20160802 20:46:30< vultraz> ok, yes
20160802 20:47:01< vultraz> it works here.
20160802 20:47:03< vultraz> moving on
20160802 20:47:36< vultraz> moving on to 7332dafd75fd8ebb5b30d844b72d8539986d5521
20160802 20:53:15< vultraz> it does NOT crash here
20160802 20:57:16-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160802 21:03:29< zookeeper> has someone made it so that giving an [object] selects that unit?
20160802 21:03:44< celticminstrel> Not as far as I know?
20160802 21:03:58< zookeeper> https://github.com/wesnoth/wesnoth/pull/682#discussion_r73200683
20160802 21:04:18< zookeeper> that's the only potential explanation i could immediately see
20160802 21:07:34-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160802 21:07:46< irker523> wesnoth: Celtic Minstrel wesnoth:master 44d171ab58aa / / (5 files in 3 dirs): Include builtin conditions in wesnoth.wml_conditions https://github.com/wesnoth/wesnoth/commit/44d171ab58aa9d01fb64f4d047d68d6a9a8ccbcf
20160802 21:08:17< celmin> …oh, it should be wml_conditionals, whoops. Oh well, code and changelog are correct.
20160802 21:11:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160802 21:11:23< vultraz> that code looks cleaner
20160802 21:12:28< celmin> What?
20160802 21:12:38< vultraz> your commit
20160802 21:12:41< vultraz> it looks cleaner
20160802 21:12:42< celmin> How so?
20160802 21:14:04< vultraz> long if/elif/else blocks are annoying
20160802 21:14:15< celmin> Oh that.
20160802 21:14:42< vultraz> > mfw now wesnoth doesn't crash when sorting in latest master >_>
20160802 21:14:58< celmin> As the changelog mentions, that commit means that these three conditional tags could be extended in Lua even while the main implementation remains C++.
20160802 21:15:08< celmin> Which was not the case before since those tags bypassed the Lua kernel.
20160802 21:16:37< vultraz> let's restore the load game code and see what happens..
20160802 21:18:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 21:26:09< vultraz> celmin: can you try sorting the Lvl or Xp columns?
20160802 21:26:26< celmin> I've been trying all columns, both directions. No issues.
20160802 21:30:14-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160802 21:32:00< vultraz> celmin: ok
20160802 21:32:12< vultraz> celmin: with or without your latest commit?
20160802 21:32:14< vultraz> er
20160802 21:32:33< vultraz> before the conditionals one
20160802 21:32:51< celmin> That was before the conditionals one.
20160802 21:33:06< celmin> It shouldn't make a difference either way though - they're totally separate areas.
20160802 21:33:21< celmin> It was with the std::function commit though.
20160802 21:33:28< celmin> It won't compile for me without that.
20160802 21:33:41< celmin> (Unless I add those & in the capture list.)
20160802 21:34:02< celmin> (I had been under the impression that that was the cause of your crash, but maybe not?)
20160802 21:35:50< vultraz> celmin: ok, so what I'm seeing right now is that if I build the commit immediately preceding the 'fix crashes commit', I can sort all columns except those that access unit:: directly, namely, XP and Level
20160802 21:35:57< vultraz> if i build at that commit, I can sort all columns
20160802 21:36:35< vultraz> the code for the load game dialog I was testing that does crash and it's accessing savegame::save_info directly
20160802 21:36:47< vultraz> however, when I first committed the recall code, I *could* sort all columns
20160802 21:37:07< vultraz> celmin: leading me to believe you're right, 7e6a1892bba0db68081a97614bf4cb05e47b1709 is the issue
20160802 21:37:07< celticminstrel> I don't see a "fix crashes commit".
20160802 21:37:26< celticminstrel> 7e6 is my fix OSX compile errors commit, right?
20160802 21:37:30< vultraz> yes
20160802 21:37:43< vultraz> celmin: by fix crashes commit i mean "Attempt to fix recall dialog crashes"
20160802 21:37:52< vultraz> celmin: so, to sum it up
20160802 21:37:53< celticminstrel> So that implies we need to stick with std::function.
20160802 21:38:08< celticminstrel> Ah, so "fix crashes commit" is the std::function commit.
20160802 21:38:12< vultraz> capturing filter_on by reference breaks calls directly to the classes
20160802 21:38:31< vultraz> since the other sorts were going through tstr_key, they were fine.
20160802 21:39:17< vultraz> (this doesn't explain why I think I was getting crashes on all columns earlier, but that doesn't seem to be the case now, so I will ignore it)
20160802 21:39:40< vultraz> celmin: so, why can't you build when capturing by value?
20160802 21:40:01< celmin> I think it's something to do with the internal type returned by std::bind.
20160802 21:40:33< celmin> I don't know the exact reason, but wrapping it in std::function fixed that.
20160802 21:40:54-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 250 seconds]
20160802 21:41:53< vultraz> it's rather messy :/
20160802 21:42:02< vultraz> is there no other solution?
20160802 21:42:23< celticminstrel> No clue. I tried several things though.
20160802 21:43:25-!- travis-ci [~travis-ci@ec2-54-167-205-59.compute-1.amazonaws.com] has joined #wesnoth-dev
20160802 21:43:26< travis-ci> wesnoth/wesnoth#10083 (master - 44d171a : Celtic Minstrel): The build is still failing.
20160802 21:43:26< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/149305331
20160802 21:43:26-!- travis-ci [~travis-ci@ec2-54-167-205-59.compute-1.amazonaws.com] has left #wesnoth-dev []
20160802 21:44:00< vultraz> let me test porting your fix to the game load instance
20160802 21:44:28< Aginor> shadowm: mordante was from a delphio background, yes? the tnaming convention is the de-facto standard in that community
20160802 21:45:29< vultraz> Aginor: did you see my last email regarding the bug tracker?
20160802 21:46:03< Aginor> vultraz: yes
20160802 21:46:49< vultraz> thoughts?
20160802 21:46:59< Aginor> it didn't address any of my concerns
20160802 21:47:17< vultraz> Anon submissions seemed to be a general concern in general, though.
20160802 21:47:26< Aginor> making me thing that I haven't mange to communicate my issues very well
20160802 21:47:48< celmin> Anonymous submissions were a big concern, yes, but not the only one as I recall.
20160802 21:47:54< vultraz> Aginor: I don't understand what you mean by "Bidirectional relations"
20160802 21:47:55< celmin> (Though I don't remember what the other concerns were.)
20160802 21:48:14< celmin> Bidirectional relations are exactly what it says on the tin. :P
20160802 21:48:26< Aginor> you link issue 1 to 1, that also establishes a link from 2 to 1
20160802 21:48:59< vultraz> Aginor: yes, GH has that.. if you reference issue 2 from issue 1, issue 2 will say it has been referenced from issue 1.
20160802 21:49:18< Aginor> vultraz: that's all well and good
20160802 21:49:35< Aginor> vultraz: but what about the one point that I'm actually really concerned about?
20160802 21:49:47< vultraz> Aginor: private submissions?
20160802 21:49:56< Aginor> apart from that I don't really have a problem moving from one crap system to a different :)
20160802 21:50:08< vultraz> they do not have that at this time
20160802 21:50:09< Aginor> vultraz: hidden/non-public tickets
20160802 21:50:21< vultraz> I think they're working on that, though.
20160802 21:50:24< celmin> Oh right, hidden issues.
20160802 21:50:41< celmin> If they're working on it we may want to consider deferring the move until it's implemented?
20160802 21:50:54< vultraz> celmin: confirmed that using std::function fixes the load game crash
20160802 21:54:05< vultraz> celmin: could you perhaps explain why capturing by reference was a problem here?
20160802 21:54:34< vultraz> Aginor: I will admit that is a pretty serious shortcoming.
20160802 21:55:02< celmin> I'm not quite sure, but it seems like it was storing a reference to a temporary.
20160802 21:55:07< vultraz> Aginor: and i will say that Jira does look more feature-ful.
20160802 21:55:14< celmin> The value returned by std::bind was never actually saved anywhere.
20160802 21:56:18< vultraz> ah
20160802 21:56:57< celmin> So I guess it was a reference to an object that no longer existed.
20160802 21:59:07-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160802 22:00:16< shadowm> Aginor: I have no idea.
20160802 22:00:37< Aginor> here's a project with a third of our open issues in GH. https://github.com/twbs/bootstrap/issues
20160802 22:01:17< Aginor> it doesn't look to me like that model will fit us that well
20160802 22:02:14< vultraz> How so?
20160802 22:02:18< vultraz> You can filter by tag.
20160802 22:03:11< celmin> Not sure what about the model is unfitting.
20160802 22:03:30< Aginor> it's so hard to find and categorise stuff ;)
20160802 22:03:39< celmin> I see.
20160802 22:05:57 * Aginor shrugs
20160802 22:06:26-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 250 seconds]
20160802 22:06:29< Aginor> the one thing I really care about is how to handle security related issues here
20160802 22:06:47< vultraz> There's a button right there where you can click to view all issues with that tag...
20160802 22:07:07< vultraz> Yes, security issues are a problem.
20160802 22:07:09< vultraz> I don't have a solution.
20160802 22:07:34-!- iceiceice [~chris@50.245.222.235] has joined #wesnoth-dev
20160802 22:07:34-!- iceiceice [~chris@50.245.222.235] has quit [Changing host]
20160802 22:07:34-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160802 22:09:06< Aginor> and bulk updates would be very nice too
20160802 22:09:27< Aginor> it'd be a pain to go and relabel a whole bunch of issues manually
20160802 22:10:06< vultraz> does jira have these things?
20160802 22:10:07< iceiceice> it might be a good idea to like, ask users or something
20160802 22:10:18< iceiceice> my experience has been that most players, when their game breaks, just forget about it,
20160802 22:10:29< iceiceice> and when i suggest that they report a bug, they explain that that's really complicated
20160802 22:10:33< iceiceice> or that they couldn't figure out how to do it
20160802 22:10:53-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20160802 22:10:55< Aginor> iceiceice: we should add a "submit a bug" form in the game itself if we want to make it easy
20160802 22:11:01< iceiceice> maybe
20160802 22:11:09< iceiceice> i think most people can handle the forum
20160802 22:11:15< Aginor> that possibly also takes a screenshot without the dialog window
20160802 22:11:17< iceiceice> so historically a lot of bugs just get posted on the forum
20160802 22:11:23< Aginor> and collects a bit of system information
20160802 22:11:35< vultraz> iceiceice: GitReports would make it very easy to submit an anon bug report. It's a simple form with few fields to fill out.
20160802 22:11:35< Aginor> and version of the game, etc
20160802 22:12:12< vultraz> Aginor: or just have the game send us this stuff automatically? :P
20160802 22:12:52< Aginor> vultraz: that's a bit mroe frowned upon, there's privacy issues there if it continiously sends information home
20160802 22:13:17< vultraz> Obviously we'd prompt the player.
20160802 22:14:44< iceiceice> idk i think gna is great for most GNU projects, esp. those where the person reporting is likely to be a programmer
20160802 22:14:52< iceiceice> but its really not ideal for a game
20160802 22:15:14< vultraz> iceiceice: the problem is that users and developers have different expectations for submitting a bug
20160802 22:15:23< iceiceice> yeah
20160802 22:16:05< vultraz> for all the talk about background data collection, I'm sure a lot of people would be pissed if they were expected to submit bug reports themselves to whatever service they were using :P
20160802 22:16:34< iceiceice> i remember getting comments about not understanding the difference between severity and priority
20160802 22:16:40< iceiceice> or not knowing if something is a security bug
20160802 22:16:47< iceiceice> and not knowing why we want them to answer all that
20160802 22:16:49-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160802 22:17:37< iceiceice> github at least is pretty simple, there's just a textbox, and you write the problem there.
20160802 22:17:55< celmin> I'd be fine with automatically sending data as long as it's opt-in - that is, the default is to not do it.
20160802 22:18:19< celmin> But that does require having a server that it can talk to about such things.
20160802 22:18:37< vultraz> iceiceice: exactly
20160802 22:18:43< iceiceice> you could try to send an email using libcurl or something maybe :)
20160802 22:18:48< vultraz> iceiceice: it's very very important that we get this done before we go on steam
20160802 22:19:19< vultraz> we need to fix bugs as quickly as possible once we're there, and making it hard for players to even report them is *bad*
20160802 22:19:50< celmin> Looks like gitreports could be self-hosted, so you could just set up a new vhost on bugs.wesnoth.org running it, if that's the route we take.
20160802 22:20:54< vultraz> I still haven't decided if we'll go with a rolling update strategy or stick to our current numbered release system, or both.
20160802 22:22:17< vultraz> Either way, we need a system where players can easily report bugs and a development plan where we push releases often.
20160802 22:22:25< vultraz> With fixes to said bugs.
20160802 22:23:05< celmin> Assuming the same versioning system as currently, there should be at least three "channels".
20160802 22:23:11< celmin> 1.14, 1.15, and 1.15+dev
20160802 22:24:14< celmin> Ideally the third one would be auto-built, not sure how plausible that is though.
20160802 22:24:37< celmin> I guess it's possible to set up Travis to store artifacts somewhere.
20160802 22:28:42-!- fabi [~fabi@176.4.89.68] has joined #wesnoth-dev
20160802 22:29:10< vultraz> celmin: btw, I can't generalize init_sorting_option since the lambda captures 'this', right?
20160802 22:30:14< celmin> Uh, I think you probably could.
20160802 22:30:21< fabi> hi
20160802 22:30:29< celmin> It doesn't really need to be a member function, honestly.
20160802 22:30:34-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160802 22:30:55< celmin> Of course it'd need a third argument if it wasn't a member function, though.
20160802 22:31:24< celmin> I have no idea how to fix Travis. :/
20160802 22:31:53< celmin> Except maybe preprocessor trickery to make it use the non-std::function version when compiling with GCC and the std::function for clang.
20160802 22:32:20< celmin> (Actually I should check if gfgtdf or Jyrki or wedge009 have any problems with either method.)
20160802 22:32:21< vultraz> template<typename Ret, T, Mem>
20160802 22:32:23< vultraz> void init_sorting_option(generator_sort_array& order_funcs, std::function<Ret(T)> filter_on, Mem capture)
20160802 22:32:24< vultraz> or something?
20160802 22:32:35< celmin> You need to repeat typename for each argument.
20160802 22:32:42< vultraz> const Mem&*
20160802 22:33:08< celmin> And Mem isn't really a good name.
20160802 22:33:35-!- atarocch [~atarocch@ipbcc2d6b3.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection]
20160802 22:33:38< celmin> Nor is capture
20160802 22:33:56< celmin> But that's the general idea.
20160802 22:35:05< vultraz> might  not be worth it
20160802 22:35:23< vultraz> it'll make the calls messier
20160802 22:35:50< celmin> Especially since you can't rely on template argument deduction.
20160802 22:36:07< celmin> Maybe you could for the third parameter.
20160802 22:36:30< celmin> Not sure if you can give a partial list and have the compiler deduce the missing ones.
20160802 22:39:53< vultraz> ill keep it as member functions
20160802 22:51:22-!- gfgtdf [~chatzilla@x4e368871.dyn.telefonica.de] has joined #wesnoth-dev
20160802 22:52:33< gfgtdf> celmin: you have teh exact erro message that was fixed by 7e6a1892bba0db68081a97614bf4cb05e47b1709 ?
20160802 22:53:33< celmin> I could check the past build logs, I guess, but the message really wasn't very helpful.
20160802 22:54:54< celmin> mattsc also had similar errors, though they weren't much more helpful than mine.
20160802 22:55:26< celmin> The errors were mainly pointing into the implementation of bind.
20160802 22:57:18< gfgtdf> celmin: maybe replacing that bind with a lambda could work?
20160802 22:57:42< celmin> Replacing binds with lambdas honestly isn't a good solution.
20160802 22:57:46< celmin> In my opinion.
20160802 22:57:47< vultraz> gfgtdf: wouldn't one need a generic lambda?
20160802 22:58:01< vultraz> celmin: i like it, for the record
20160802 22:58:08< celmin> Sure it might work, but it'll take a lot more space.
20160802 22:58:19< gfgtdf> celmin: note that lambdas are often faster than std::bind , the reason is that std::bind takes a function pointer while labdaas create some function object where the fnction is known at compile time.
20160802 22:58:39< gfgtdf> celmin: that is, unless your compiler optimites that out.
20160802 22:58:47< gfgtdf> optimizes*
20160802 22:59:00< celmin> Which I would expect it to do in the majority of cases.
20160802 22:59:22< fabi> Does runtime really matter in the code part you talk about?
20160802 22:59:43< celmin> I don't think it's really a concern, but it's true that the function in question is being called as the comparator of a sort.
20160802 23:00:47< celmin> So if there's 100 units on the recall list, it'll be called probably around 5 times.
20160802 23:00:56< fabi> well...
20160802 23:01:05< celmin> If there's 1000 units, around 7 times.
20160802 23:01:17< celmin> Assuming the sort is O(log n).
20160802 23:01:29< gfgtdf> celmin: there is n o()long n osrt
20160802 23:01:34< fabi> the question is how often is that function called?
20160802 23:01:39< gfgtdf> celmin: it usualyl (n*log(n))
20160802 23:01:41< fabi> every time you open the dialog?
20160802 23:01:44< celmin> Oh, nlogn, sorry.
20160802 23:01:47< fabi> then it doesn't matter
20160802 23:01:52< celmin> Okay, that's a bit more.
20160802 23:02:15< vultraz> celmin: what would a lambda look like as the caller?
20160802 23:02:18< gfgtdf> fabi: well it makes the dialog open 1(2 second faster than this is important
20160802 23:02:22< celmin> fabi: So it's called n*log(n) times each time you click on a listbox header to choose the sort direction.
20160802 23:02:32< celmin> It's not called when the dialog first opens.
20160802 23:02:49< celmin> At least, I don't think it is - initially no header has a directional marker.
20160802 23:03:07< celmin> vultraz: What?
20160802 23:03:31< celmin> So 500 times for 100 units, I guess.
20160802 23:03:44< gfgtdf> vultraz: init_sorting_option(order_funcs, [](unit_const_ptr u){ return u->type_name.str(); });
20160802 23:03:55< celmin> Well, 460. And 6900 times for 1000 units.
20160802 23:03:55< vultraz> hm
20160802 23:03:57< vultraz> I like
20160802 23:04:08< fabi> 1000 units in a recall list?
20160802 23:04:16< celmin> Yeah, I don't think that's likely.
20160802 23:04:26< celmin> Though in something like LotI or whatever, who knows.
20160802 23:04:26< fabi> code first
20160802 23:04:28< gfgtdf> vultraz: i actuall think thats easiert ot read then (u.get()->*fcn)().str() + std::bind
20160802 23:04:30< fabi> optimize later
20160802 23:04:35< celmin> ^
20160802 23:04:40< fabi> and only if you have prove it is necessary
20160802 23:04:43< vultraz> gfgtdf:  it 
20160802 23:04:45< vultraz> is
20160802 23:04:46< celmin> I do think gfgtdf is overthinking the optimization.
20160802 23:04:49< fabi> write code that is easy to read
20160802 23:05:04< gfgtdf> vultraz: wait mayb it needs init_sorting_option(order_funcs, [](unit_const_ptr u){ return u.get()->type_name.str(); }); but still
20160802 23:05:19< vultraz> ill test
20160802 23:05:26< celmin> I personally think that the std::bind is easy to read, but I guess the lambda form is comparable in this case, since there's only one unbound argument.
20160802 23:09:21< vultraz> celmin: using this would allow us to do away with the tstr_key/trait_key wrappers
20160802 23:09:31< celmin> Yes.
20160802 23:10:07< celmin> But I don't know if it'll compiled for me without the std::function.
20160802 23:10:27< celmin> Though, since I think all the errors were bind-related, it might work.
20160802 23:15:43< vultraz> plus, this is cleaner overall 
20160802 23:15:50< vultraz> since it simplifies the function arguments
20160802 23:17:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160802 23:17:05< vultraz> hmmm
20160802 23:17:10< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\gui\dialogs\unit_recall.cpp|255|error: 'u.boost::intrusive_ptr<T>::get<const unit>()->unit::type_name' does not have class type|
20160802 23:17:41< fabi> By the way, n*log(n) is good enough so that you do not have to worry that much in most cases but really often called things.
20160802 23:18:13< fabi> like drawing routines
20160802 23:18:16< vultraz> i do not understand this error
20160802 23:18:42< celmin> I think probably the only other place in Wesnoth where I'd consider performance to be worth worrying about is the AI.
20160802 23:18:46< celmin> So, graphics and AI.
20160802 23:19:00< gfgtdf> vultraz: i think it shodul be type_name() instead of just type_name
20160802 23:19:01< celmin> vultraz: Forget a ()?
20160802 23:19:30< vultraz> ah yes
20160802 23:19:44< vultraz> so with this, do we still want to lambda capture by reference or value?
20160802 23:19:50< vultraz> in init_sort_option
20160802 23:19:54< vultraz> sorting*
20160802 23:20:01< fabi> celmin: yes, ai and what it depends on. Like pathfinding.
20160802 23:20:24< celmin> Oh yeah, pathfinding.
20160802 23:20:28< fabi> But pathfinding is a problem being worked on since ages in computer science.
20160802 23:20:34< fabi> So no rocket science involved.
20160802 23:20:35< gfgtdf> vultraz: by value
20160802 23:22:18-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160802 23:22:30< vultraz> ancestral: any news on the package?
20160802 23:22:35< fabi> celmin: the ai makes also often use of filtering units. In general, the filters must work fast.
20160802 23:22:55-!- Duthlet [~Duthlet@dslb-178-005-055-087.178.005.pools.vodafone-ip.de] has quit [Quit: leaving]
20160802 23:23:00< celmin> Sure.
20160802 23:23:34< fabi> Every other aspect. Prefer readability over überoptimierung.
20160802 23:24:17< celmin> Vision calculation maybe.
20160802 23:24:24< fabi> oh yes.
20160802 23:24:33< fabi> But that is mostly pathfinding.
20160802 23:24:37< celmin> That's related to pathfinding, yeaj.
20160802 23:24:39< celmin> ^yea
20160802 23:24:41< celmin> ^yeah
20160802 23:24:56< celmin> I guess in Wesnoth it might be the same.
20160802 23:26:02< fabi> indeed
20160802 23:27:23< Aginor> fabi: UI layout too
20160802 23:27:35< fabi> well
20160802 23:27:41< fabi> that is a upstream problem
20160802 23:27:41< Aginor> sadly ;)
20160802 23:27:50< celmin> Huh?
20160802 23:28:13< Aginor> GUI2 layouts are rather slow
20160802 23:28:16< fabi> use a gui that is maintained by a stuff you need maintaining a gui
20160802 23:28:26< fabi> and make it a upstream problem
20160802 23:28:32< Aginor> indeed
20160802 23:28:35< fabi> s/stuff/staff
20160802 23:28:46< fabi> but I repeat myself for 100 times
20160802 23:28:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160802 23:29:18< Aginor> fabi: I agree with your points though :)
20160802 23:30:29< celmin> The problem is that replacing GUI2 isn't any easier than sticking with it.
20160802 23:31:24< fabi> Although, I am not that angry anymore. I like how all that steam stuff seems to bring again some life in the franchise.
20160802 23:32:07< fabi> celmin: yes
20160802 23:32:38< fabi> celmin: I do not think replacing gui2 in the old engine is a good idea. Recode the engine. Again, I repeat myself.
20160802 23:32:48< celmin> That's a worse idea.
20160802 23:33:19< fabi> You can calculate when a piece of software has come to his end of life.l
20160802 23:33:41< celmin> That's not something that can be calculated.
20160802 23:34:17< fabi> Recode efford < maintainance effort * x
20160802 23:35:03< vultraz> fabi: we're working on Wesnoth 2 in Anura. New game, new gameplay, new story. Go contribute to that if you really want to ditch this engine.
20160802 23:35:26< fabi> ah no
20160802 23:35:36< fabi> I don't think Anura is a good choice.
20160802 23:35:47< fabi> And my own effords are far to advanced.
20160802 23:35:58< ancestral> Conversation here is getting interesting
20160802 23:36:15< celmin> Interesting?
20160802 23:36:19< vultraz> advanced, you say?
20160802 23:36:23< Aginor> 11:34 < fabi> Recode efford < maintainance effort * x
20160802 23:36:27< fabi> it is the same all the time
20160802 23:36:31< ancestral> vultraz: I have it done, but trying to give something to celmin to see if it works for him
20160802 23:36:32< Aginor> I don't think we're anywhere near that to be honest
20160802 23:36:33< fabi> and not interresting anymore
20160802 23:36:40< ancestral> “interesting” meaning tense
20160802 23:36:50< Aginor> as we'd need to maintain feature/addon compatability
20160802 23:36:58< Aginor> and that'll be Hard in a rewrite
20160802 23:36:59< celmin> Tense huh
20160802 23:37:47< celmin> ancestral: Trying to give me something? What's that mean?
20160802 23:37:51< fabi> vultraz: Please tell me if there is something new. The last time I looked there was no work on the anura Wesnoth2 repository
20160802 23:37:56< Aginor> I've said it in the past, and I'll repeat it. I think a rewrite will be a good way to kill the game
20160802 23:38:04< fabi> How many people are working on it actively?
20160802 23:38:05< ancestral> celmin: A binary to test on 10.8
20160802 23:38:10< celmin> 10.7
20160802 23:38:13< ancestral> 10.7
20160802 23:38:14< celmin> I don't have 10.8
20160802 23:38:24< vultraz> fabi: https://drive.google.com/file/d/0B-mR9s8FduLLbkJwNzJ0UEtOU2s/view?usp=sharing
20160802 23:38:31< vultraz> fabi: 3
20160802 23:38:36< celmin> My laptop probably could be upgraded to 10.8, but 10.8 is before the free updates and it can't run 10.9.
20160802 23:38:52< fabi> vultraz: Which are?
20160802 23:38:56< fabi> sorry
20160802 23:38:59< fabi> who are?
20160802 23:39:02< vultraz> fabi: me, dave, and krista
20160802 23:39:41< fabi> vultraz: Maybe you follow dave's idea to use a complete different non compatible game format.
20160802 23:39:58< vultraz> the goal isn't to make this W1-compatible 
20160802 23:40:03< fabi> nice
20160802 23:40:09< fabi> I like to hear that.
20160802 23:40:23< celmin> From what I hear, the goal is not to make a wesnoth clone either.
20160802 23:40:53< vultraz> Correct
20160802 23:40:56< vultraz> AT least, not yet
20160802 23:40:56< irker523> wesnoth: Charles Dang wesnoth:master df846460269f / src/gui/dialogs/ (unit_recall.cpp unit_recall.hpp): Lambda-based replacement for e75eaca5a00f https://github.com/wesnoth/wesnoth/commit/df846460269fcfcc89e8f38cc20dd9fab9ec781c
20160802 23:41:08< vultraz> celmin: please test  that that builds ^
20160802 23:41:10< ancestral> celmin: This might be easier if I just took your libs :-\
20160802 23:41:59< celticminstrel> Well, we could try that, I guess.
20160802 23:41:59< fabi> vultraz: I wish the project good luck. And I will contribute at some time in the more distant future.
20160802 23:42:22< celticminstrel> I don't know if my libs will work on your computer though.
20160802 23:42:38< celticminstrel> And I doubt my libs would work on a general Mac without some install_name_tool twiddling.
20160802 23:42:40< ancestral> fabi: With a release on Steam, we may get an influx of new blood, and new ideas
20160802 23:43:02< fabi> ancestral: Oh yes. 
20160802 23:43:11< celmin> So, did you have a build you were going to upload for me to try?
20160802 23:43:35< celmin> (We may, but how many of the Steam users will be programmers?)
20160802 23:44:56< ancestral> Yes
20160802 23:45:31< ancestral> Zipping momentarily
20160802 23:45:32< ancestral> Thanks
20160802 23:45:55< fabi> ancestral: I hope the community around Wesnoth will grow after the steam release.
20160802 23:46:01< ancestral> Me too
20160802 23:46:16< fabi> Releasing on steam should have been done since ages.
20160802 23:46:25< ancestral> If you haven’t seen the greenlight page, there’s an incredible amount of praise
20160802 23:46:28< fabi> I love vultraz and everyone else who make it happen finally.
20160802 23:46:46< vultraz> it wasm
20160802 23:46:48< fabi> I never had a doubt Wesnoth would.
20160802 23:46:54< vultraz> wasn't*
20160802 23:46:55< vultraz> easy
20160802 23:47:18< ancestral> celmin: ~10 minutes
20160802 23:47:31< ancestral> Upload speeds are slower than download speeds here
20160802 23:47:50< fabi> I think the game has still a great future, just not the current engine.
20160802 23:49:25< fabi> The real treasure is all hidden beyond /data and on the addon server.
20160802 23:49:35< fabi> not in /src
20160802 23:55:06< celmin> Ah.
20160802 23:56:12< celmin> vultraz: That compiles forme.
20160802 23:56:14< celmin> ^for me
20160802 23:56:19< vultraz> \ o /
20160802 23:56:26< vultraz> praise gfgtdf 
20160802 23:56:30< celmin> I've been following the greenlight page, yeah.
20160802 23:59:13< vultraz> really, the lambda solution here is a lot easier to read
--- Log closed Wed Aug 03 00:00:15 2016