--- Log opened Tue Aug 09 00:00:02 2016
--- Day changed Tue Aug 09 2016
20160809 00:00:02< celticminstrel> child_range returns a std::pair after all.
20160809 00:00:36< vultraz> huh that does work
20160809 00:00:50< vultraz> perhaps you could add a wrapper function for that
20160809 00:03:05< vultraz> (heh. std::gcd is in c++17)
20160809 00:03:59< celticminstrel> I don't think you can add a wrapper function for that.
20160809 00:04:28< celticminstrel> Even if you could, it wouldn't work in constructor initialization lists.
20160809 00:05:11< celticminstrel> Well, I suppose a function returning a vector is possible...
20160809 00:09:13< celticminstrel> gfgtdf disallowed commas in unit type IDs, right?
20160809 00:09:39< gfgtdf> celticminstrel: yes i did
20160809 00:13:59< celticminstrel> What was the exception type thrown by stoi again...?
20160809 00:15:18< vultraz> invalid_argument
20160809 00:15:20< vultraz> I think
20160809 00:20:15-!- Bonobo [~Bonobo@2001:44b8:254:3200:119f:1e96:66ea:c790] has joined #wesnoth-dev
20160809 00:29:15-!- Bonobo [~Bonobo@2001:44b8:254:3200:119f:1e96:66ea:c790] has quit [Ping timeout: 264 seconds]
20160809 00:29:39-!- Bonobo [~Bonobo@2001:44b8:254:3200:3801:7e55:9c62:35d1] has joined #wesnoth-dev
20160809 00:29:40< irker320> wesnoth: Charles Dang wesnoth:master b4d80cc662f9 / src/gui/dialogs/preferences_dialog.cpp: tpreferences: use a lambda to sort advanced preferences https://github.com/wesnoth/wesnoth/commit/b4d80cc662f9b4930586e43f06c8e918e657773d
20160809 00:34:04< vultraz> I think gfgtdf's code for the sorting is good
20160809 00:34:36< vultraz> prevents from having to duplicate init_sorting_option
20160809 00:36:57< vultraz> only thing is it seems weird to have specify index as an argument when you don't use it
20160809 00:37:28< celticminstrel> Presumably that means you don't need to specify it.
20160809 00:41:00< vultraz> huh
20160809 00:41:02< vultraz> ..\..\src\gui\widgets\listbox.hpp|240|error: 'void gui2::tlistbox::register_sorting_option(int, const Func&) [with Func = gui2::tpreferences::initialize_members(gui2::twindow&)::<lambda(int)>]', declared using local type 'const gui2::tpreferences::initialize_members(gui2::twindow&)::<lambda(int)>', is used but never defined [-fpermissive]|
20160809 00:44:08< vultraz> not sure what this means
20160809 00:44:58< vultraz> what is it asking be defined
20160809 00:45:39< gfgtdf> vultraz: you have register_sorting_option( in the headre file of the listbox ?
20160809 00:45:42< gfgtdf> header*
20160809 00:45:58< gfgtdf> vultraz: you may not put it in the listbox.cpp file.
20160809 00:46:28< vultraz> the definition is in the header
20160809 00:46:33< vultraz> does the implementation need tobe there too?
20160809 00:46:50< gfgtdf> vultraz: defeintion is teh same as implementation
20160809 00:46:54< gfgtdf> vultraz: you mean declaration ?
20160809 00:47:00< vultraz> er, yes
20160809 00:47:03< gfgtdf> vultraz: everythign must be in the header.
20160809 00:47:57< gfgtdf> vultraz: when using templates, everythign must be involved while parsing the current file. unless you explictly instanciate it or given tempalte arguemnt in the cpp file (which is not possible for lambdas)
20160809 00:48:16< vultraz> ahh
20160809 00:50:11< celticminstrel> I'm changing the statistics save format.
20160809 00:50:18< gfgtdf> vultraz: the general rule is, that for all template stuff the implementatio need to be in the same file as the declaration, usually like mormal inline methods.
20160809 00:50:33< celticminstrel> Instead of unit1=value unit2=value, it'll be value=unit1,unit2
20160809 00:50:54< celticminstrel> Then we don't have to worry about punctuation other than commas in unit IDs.
20160809 00:51:07< celticminstrel> Or spaces.
20160809 00:51:13< vultraz> hmmm
20160809 00:51:19< vultraz> builds, but doesn't work
20160809 00:51:33< celticminstrel> (Unless there's other places where unit IDs are used as WML keys, but those should be squashed too if they exist.)
20160809 00:51:49< vultraz> you DO need an index argument when filtering on vectors 
20160809 00:51:55< vultraz> but the index isn't set to anything
20160809 00:52:06< gfgtdf> vultraz: whats your code currently?
20160809 00:52:12< celticminstrel> I have no idea what you're talking about...
20160809 00:53:49< gfgtdf> vultraz: hm i ssaw in my original code it shoudl orcourse be ' f(lhs) < f(rhs)' instead of ' f(lhs) < f(lhs)'
20160809 00:54:20< vultraz> oh didn't catch that
20160809 00:56:44< vultraz> it works \ o /
20160809 00:56:50< celticminstrel> \o/
20160809 00:57:08< vultraz> tho I'd like to know why it works
20160809 00:57:15< vultraz> hotkey_list.register_sorting_option(0, [this](const int i) { return visible_hotkeys_[i]->description.str(); });
20160809 00:57:21< vultraz> what sets i?
20160809 00:57:35< celticminstrel> That's obvious. It's a function parameter.
20160809 00:58:14< vultraz> yes
20160809 00:58:34< vultraz> I guess it's the value of lhs/rhs...
20160809 00:58:37< celticminstrel> I don't think it's good to take i as a parameter... though I guess that might be what allows you to make it more generic...
20160809 00:58:45< celticminstrel> Yes, that's what it is indeed.
20160809 00:59:10< vultraz> don't you *need* to take i as a parameter?
20160809 00:59:33< celticminstrel> I think it's better to take visible_hotkeys_[i] as the parameter.
20160809 00:59:46< vultraz> sure, but how would one do that
20160809 00:59:54< celticminstrel> But that might defeat genericness. Not sure.
20160809 01:02:17< vultraz> if you could pass that as the value of f I guess
20160809 01:02:33< vultraz> er, no
20160809 01:02:48< vultraz> f is the function..
20160809 01:02:50< vultraz> yeah I dunno
20160809 01:03:27< vultraz> you'd need three arguments
20160809 01:03:30< vultraz> instead of two
20160809 01:04:06< vultraz> or
20160809 01:04:08< vultraz> wait
20160809 01:04:09< vultraz> no
20160809 01:04:21< vultraz> celticminstrel: I think it means only vectors could be passed
20160809 01:04:27< vultraz> or stuff that uses [i]
20160809 01:04:49< vultraz> but that's the only thing that's used
20160809 01:04:51< vultraz> anyway
20160809 01:05:23< vultraz> but you'd still need three arguments, I think
20160809 01:05:48< vultraz> f(m[lhs])
20160809 01:05:50< vultraz> I think
20160809 01:05:51< vultraz> ?
20160809 01:06:00< vultraz> celticminstrel: is that right?
20160809 01:06:07< celticminstrel> Maybe?
20160809 01:06:21< celticminstrel> I mean, I don't see anything wrong about it.
20160809 01:06:28< vultraz> so you'd end up with...
20160809 01:07:29< vultraz> hotkey_list.register_sorting_option(0, visible_hotkeys_, [](hotkey::hotkey_command* key) { return key->description.str(); });
20160809 01:07:41< vultraz> I think?
20160809 01:07:58< celticminstrel> That sounds about right.
20160809 01:08:07< vultraz> this doesn't seem like an improvement
20160809 01:08:23< celticminstrel> It does to me, but a minor one I guess.
20160809 01:08:29< vultraz> if one could just do (auto key), maybe
20160809 01:08:43< celticminstrel> You can in c++14, of course.
20160809 01:08:50< vultraz> of course
20160809 01:09:04-!- gfgtdf [~chatzilla@x4e32b578.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20160809 01:09:04< celticminstrel> BTW, don't just use auto.
20160809 01:09:20< celticminstrel> Most of the time you actually want "const auto&" or "auto&".
20160809 01:09:24< vultraz> right
20160809 01:10:00-!- gfgtdf [~chatzilla@x4e36a72a.dyn.telefonica.de] has joined #wesnoth-dev
20160809 01:11:28< vultraz> eh, I think might have to stick with the index method
20160809 01:11:45< vultraz> since I just realized some dialogs need (*m)[i].something
20160809 01:11:50< celticminstrel> Okay.
20160809 01:12:03< celticminstrel> (Those dialogs could pass *m instead of m, you know.)
20160809 01:12:10< vultraz> hmm
20160809 01:12:39< vultraz> gfgtdf: thoughts?
20160809 01:16:57< gfgtdf> vultraz: i perosnalyl think the just passing a function that takes the index makes the listbox.hpp code easier to understand, while havin no drawback on the othe side.
20160809 01:17:06< irker320> wesnoth: Celtic Minstrel wesnoth:master fba34c1eeea6 / src/statistics.cpp: Don't use unit IDs as WML keys when saving statistics https://github.com/wesnoth/wesnoth/commit/fba34c1eeea6cbd893feeb0c3c827dd4f71aaa7a
20160809 01:17:17< vultraz> ok
20160809 01:18:55< celticminstrel> The config_writer version in particular is probably less efficient this way, but not sure how (or if) I can fix that...
20160809 01:19:21< gfgtdf> i want to add the 'dont store events in each safefile' to the easycosing page, and opinion whetehr its easycosing or notsoeasycoding ?
20160809 01:20:01< celticminstrel> Doesn't feel easy to me...
20160809 01:20:26< gfgtdf> ok will add it to notsoeasycosing
20160809 01:20:40< celticminstrel> And check your spelling.
20160809 01:29:03< gfgtdf> added it to that page
20160809 01:40:14< irker320> wesnoth: Charles Dang wesnoth:master a30d816ac799 / src/gui/ (13 files in 3 dirs): Generalize listbox sorting option setup (thanks to gfgtdf) https://github.com/wesnoth/wesnoth/commit/a30d816ac7995ca6a2382de2268e765b9292f7ee
20160809 01:40:20< vultraz> sooo much simpler now :D
20160809 01:40:56< vultraz> and, as a bonus, no longer need to create those generator_sort_array objects
20160809 01:42:56< vultraz> lambdas are truly awesome
20160809 01:54:27< celticminstrel> vultraz: What about removing generator_sort_array, then?
20160809 01:54:43< vultraz> it's still used
20160809 01:54:48< vultraz> in the listbox implementation
20160809 01:54:50< celticminstrel> Ah... okay then.
20160809 02:00:30-!- jamit [~jamit@97-87-12-18.dhcp.mdsn.wi.charter.com] has joined #wesnoth-dev
20160809 02:02:43< gfgtdf> vultraz: is the gui2 unit list working ?
20160809 02:03:36< vultraz> gfgtdf: I just need to add the contents of the status column
20160809 02:03:51< gfgtdf> vultraz: ok
20160809 02:04:22< vultraz> sadly one cannot use ~BLIT() on a surface created at runtime
20160809 02:04:28< vultraz> or pass such a thing to the image widget
20160809 02:04:30< vultraz> >_>
20160809 02:05:12< gfgtdf> vultraz: can'T you just use sdls draw methods directly if you want to blit things ons urfaces?
20160809 02:05:28< vultraz> perhaps
20160809 02:05:38< vultraz> but then I still can't pass that to timage
20160809 02:06:14< gfgtdf> vultraz: so you wan to blit a surface on image?
20160809 02:06:58< vultraz> ok, so the old unit list used the status icons to indicate status
20160809 02:07:09< vultraz> in gui2, it's 1 image per widget
20160809 02:07:28< vultraz> so either i give the dialog a bunch of image widgets in a row and hide the non-relevant ones
20160809 02:07:42< vultraz> or I somehow construct a surface at runtime and display that
20160809 02:07:50< vultraz> problem is that gui2's image widget takes a filename
20160809 02:07:51-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160809 02:07:52< vultraz> not a surface
20160809 02:09:36< vultraz> I'll just do the former, since there are only 4
20160809 02:10:13< gfgtdf> vultraz: hmm you could creat a custom widget but it might be more work secially if there is another option liek you said.
20160809 02:11:01< celticminstrel> "there are only 4"
20160809 02:11:06< celticminstrel> Pretty sure that's not true.
20160809 02:11:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160809 02:11:51< gfgtdf> celticminstrel: i think this might refer to that the right side panal has also just space for 4 statuses, just a guess though.
20160809 02:12:04< celticminstrel> I don't think that's true either.
20160809 02:12:30< vultraz> celticminstrel: it's only designed to show slowed, poisoned, petrified, or invisible
20160809 02:12:40< celticminstrel> Although, I suppose maybe I haven't ever tried having more than four statuses at a time...
20160809 02:12:54< celticminstrel> Are there other core statuses with an icon?
20160809 02:13:02< vultraz> dont think so
20160809 02:13:08< vultraz> there could be custom umc ones, though
20160809 02:13:14< vultraz> so this is not an optimal solution
20160809 02:13:16< celticminstrel> Exactly.
20160809 02:13:27< celticminstrel> And not just UMC!
20160809 02:13:31< vultraz> simplest solution
20160809 02:13:32< vultraz> use text :P
20160809 02:13:34< celticminstrel> DW and UtBS use custom statuses, right??
20160809 02:13:40< vultraz> yes
20160809 02:13:43< celticminstrel> Text would work as a stopgap, sure...
20160809 02:13:51< vultraz> true
20160809 02:14:03< gfgtdf> vultraz: afaik umc ones coundt add icons werent int the unit status list beforeeoigher, so this shoudlnt block the gui2 status list
20160809 02:14:05< vultraz> maybe I'll just use text until I can figure out a better solution
20160809 02:14:16< gfgtdf> couldn't
20160809 02:14:18< celticminstrel> What's the commented-out bit on line 64?
20160809 02:14:26< vultraz> celticminstrel: file?
20160809 02:14:31< celticminstrel> unit_list
20160809 02:14:34< celticminstrel> .cpp
20160809 02:14:37< vultraz> oh
20160809 02:14:47< vultraz> yeah, for some reason that code doesn't work
20160809 02:14:51< vultraz> and the above loop is needed
20160809 02:15:01< vultraz> dunno why
20160809 02:15:13< celticminstrel> What's the return type of get_units...
20160809 02:15:23< celticminstrel> Ah, unit_map.
20160809 02:15:28< vultraz> unit_map
20160809 02:15:59< vultraz> for some reason I also needed to initialize unit_list_ as std::make_shared<std::vector<unit_const_ptr> >()
20160809 02:17:16< gfgtdf> vultraz: mabe becasue te type is a std::shared_ptr<std::vector<unit_const_ptr> >  ?
20160809 02:17:19< gfgtdf> vultraz: i wonder why
20160809 02:17:33< vultraz> yes but I don't have to do this other places I use that
20160809 02:17:36< vultraz> like the recall dialog
20160809 02:18:00< vultraz> oh come on
20160809 02:18:03< vultraz> are you (@&#*()#@& kidding me
20160809 02:18:13< vultraz> unit has no list of statuses
20160809 02:18:18< vultraz> only individual functions
20160809 02:18:32< irker320> wesnoth: Celtic Minstrel wesnoth:master f56feea0b867 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update XCode project https://github.com/wesnoth/wesnoth/commit/f56feea0b8673c8fd4413162bc175530d9ff5a26
20160809 02:18:45< celticminstrel> vultraz: Check how the ThemeWML handles it?
20160809 02:18:53< gfgtdf> vultraz: unit::get_states()  ?
20160809 02:19:09< vultraz> oh
20160809 02:19:13< celticminstrel> That might not be what you want though. Ideally it should go through the Lua kernel.
20160809 02:19:31< gfgtdf> vultraz: i also recoomaned to change those classes no to use std::shared_ptr<std::vector<unit_const_ptr> >  
20160809 02:19:40< vultraz> celticminstrel: "// Backwards compatibility for not_living. Don't remove before 1.12"
20160809 02:19:43< vultraz> celticminstrel: something to remove?
20160809 02:20:00< celticminstrel> You haven't given me enough context.
20160809 02:20:00< gfgtdf> vultraz: just use 'std::vector<unit_const_ptr> ' or 'std::vector<unit_const_ptr>&'.
20160809 02:20:24< vultraz> celticminstrel: look in unit::get_states and get_state
20160809 02:20:26< vultraz> gfgtdf: ok
20160809 02:20:39< vultraz> gfgtdf: I honestly don't know why it used a shared_ptr before
20160809 02:20:46-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160809 02:20:48< vultraz> I just copied that from the gui1 version
20160809 02:21:04< vultraz> celticminstrel: and set_state
20160809 02:21:09-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has joined #wesnoth-dev
20160809 02:21:10< travis-ci> wesnoth/wesnoth#10235 (master - a30d816 : Charles Dang): The build was broken.
20160809 02:21:10< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/150809301
20160809 02:21:10-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has left #wesnoth-dev []
20160809 02:21:12< celticminstrel> I distinctly recall mentioning that it was useless.
20160809 02:22:02< vultraz> DAMMIT TRAVIS
20160809 02:22:06< tad_> Is there a way to set facing for an item image? I have one moving in sw and suddenly jumping to face se and would like to stop that if I can.
20160809 02:22:13< celticminstrel> So this status thing, is that in unit_preview_pane?
20160809 02:22:30< gfgtdf> vultraz: i woldnt remove not_living, sicne there is not depreation notice a i see
20160809 02:22:31< vultraz> celticminstrel: what?
20160809 02:22:31< celticminstrel> tad_: Huh? I'm not sure what you're talking about.
20160809 02:22:42< gfgtdf> vultraz: neigher was there a warning in the code when its used
20160809 02:22:43< vultraz> gfgtdf: there must have been one in 1.11
20160809 02:22:50< celticminstrel> vultraz: You're trying to figure out how to show statuses.
20160809 02:22:55< vultraz> gfgtdf: since this says "not before 1.12"
20160809 02:23:06< vultraz> celticminstrel: oh, I'm doing this in unit_list
20160809 02:23:11< vultraz> tunit_list
20160809 02:23:16< tad_> Moveunit fake stops with it facing sw then [item] drops a static item buit it's facing se and I don't want the jump if I can avoid it
20160809 02:23:18< vultraz> since it's a dialog-specific thing
20160809 02:23:30< vultraz> celticminstrel: I haven't added anything yet
20160809 02:23:38< gfgtdf> vultraz: there is even mainline content that uses it https://github.com/wesnoth/wesnoth/blob/master/data/test/scenarios/feeding.cfg#L78
20160809 02:23:56< vultraz> huh
20160809 02:24:42< celticminstrel> Uses what?
20160809 02:24:57< gfgtdf> vultraz: so if you wan to remove it at soem point 'd start with adding a  warning in where it says 'Backwards compatibility for not_living...'
20160809 02:25:01< celticminstrel> tad_: Is there something like a "flip" key?
20160809 02:25:01< gfgtdf> celticminstrel: not_living
20160809 02:25:13< celticminstrel> Ah.
20160809 02:25:41< tad_> I don't know the ~ things well. I will look again.
20160809 02:25:50-!- gfgtdf [~chatzilla@x4e36a72a.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0/20160726073904]]
20160809 02:26:02< celticminstrel> Not what I meant, though I suppose that could work too - ~FL()
20160809 02:26:27< celticminstrel> Maybe a "mirror" key or something?
20160809 02:26:50< tad_> No key for [item] facing= would be nice but not there
20160809 02:27:30< celticminstrel> Try ~FL() on the end of the image path
20160809 02:28:09< vultraz> looks like travis doesn't like the lambdas 
20160809 02:28:19< vultraz> tough
20160809 02:28:57< tad_> ~FL() did the trick. Thanks. Ya'know even finding those ~things on the wiki takes digging :P
20160809 02:29:21< celticminstrel> It's under ImagePathFunctionWML.
20160809 02:29:27< celticminstrel> Even though it's not really WML.
20160809 02:29:46< vultraz> celticminstrel: can you successfully build the lambda commit?
20160809 02:30:01< celticminstrel> I assume so, haven't tested yet.
20160809 02:30:22< celticminstrel> GCC 4.7 appears to be misinterpreting the lambdas as braced-initializer-lists? :S
20160809 02:30:34< tad_> OK. Gimme a few minutes to clean up and I'm pushing updates for HttT PRs with todays changes. That finishes the items discussed so far. I'm going to work on another scenario waiting for more comments from y'all
20160809 02:30:43< celticminstrel> Oh, wait, no.
20160809 02:31:00< vultraz> there is a brace initilizer list
20160809 02:31:07< vultraz> initializer 
20160809 02:31:12< celticminstrel> Hmm, that could be the sort of thing that my compiler has problems with too... let me try it...
20160809 02:31:27< vultraz> I think it's a rather elegant solution
20160809 02:31:34-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160809 02:31:42< celticminstrel> My clang has a bug with how it handles braced-initializers.
20160809 02:31:46< vultraz> :|
20160809 02:31:52< vultraz> update your clang
20160809 02:32:05< celticminstrel> For example, suppose you have a class that has an initializer_list constructor. Then make a vector of that class.
20160809 02:32:13< celticminstrel> Let's say it's a location clas.
20160809 02:32:17< celticminstrel> ^class
20160809 02:32:35< celticminstrel> You should be able to initialize it with eg {{1,2}, {3,4}, {5,6}}, but my clang chokes on that.
20160809 02:33:04< celticminstrel> (That's why I didn't suggest eliminating uses of std::make_pair.)
20160809 02:33:12< celticminstrel> Okay yeah, my clang errors on that line.
20160809 02:33:32< celticminstrel> But it seems to be giving a possible fix, let's see if that makes any sense...
20160809 02:33:39 * vultraz curses
20160809 02:33:58 * vultraz curses again because get_states isn't working right
20160809 02:34:11< celticminstrel> Looks like my clang accepts it if you double the braces.
20160809 02:34:30< vultraz> but will travis
20160809 02:34:37< celticminstrel> We shall find out!
20160809 02:34:52< vultraz> will you update him to 4.8 already
20160809 02:35:01< celticminstrel> Why?
20160809 02:35:17< vultraz> we agreed to do so
20160809 02:35:21< celticminstrel> Last I remember we agreed to support 4.7. I know you've been talking about changing that, but I don't remember seeing reasons or anything.
20160809 02:35:33< celticminstrel> Or analysis of the fallout or whatever.
20160809 02:35:43< vultraz> we... went over all that
20160809 02:35:45< vultraz> :|
20160809 02:35:48< celticminstrel> What does it mean in terms of OS support?
20160809 02:36:03< celticminstrel> Maybe you did, I just don't remember it.
20160809 02:36:14< vultraz> we concluded it's fine
20160809 02:36:23< vultraz> losing debian oldstable is acceptable
20160809 02:36:33< celticminstrel> If I recall, there was one major distro that it drops.
20160809 02:36:45< celticminstrel> Arch Linux maybe?
20160809 02:36:55< celticminstrel> I dunno how major that is these days, but...
20160809 02:37:45< vultraz> uhh
20160809 02:38:03< vultraz> I don't remember that coming up
20160809 02:38:21< celticminstrel> Based on the table I made awhile ago.
20160809 02:38:44< iceiceice> celticminstrel, i thought it was mint
20160809 02:38:50< celticminstrel> Maybe it's acceptable to drop it, I dunno.
20160809 02:38:53< iceiceice> arch is rolling release, it always has the most up to date
20160809 02:38:55< celticminstrel> Might've been Mint, yeah.
20160809 02:38:57< iceiceice> (more or less)
20160809 02:39:03< iceiceice> but i tink there was a new mint major release
20160809 02:39:06< vultraz> yes
20160809 02:39:10< vultraz> you mentioned this
20160809 02:39:27< celticminstrel> Oh? So what version of GCC does the latest Mint major release ship?
20160809 02:39:34< iceiceice> its based on xenial
20160809 02:39:42< iceiceice> (ubuntu 16.04)
20160809 02:39:54< iceiceice> i think it ships with gcc 5.4.0
20160809 02:39:58< iceiceice> would have to check though
20160809 02:40:16< iceiceice> i am considering to switch back to mint actually
20160809 02:40:28< iceiceice> i am currently on ubuntu, i had to switch because mint didn't have a new enough mingw-w64
20160809 02:40:35< iceiceice> it was only 4.8.4 :p
20160809 02:40:45< celticminstrel> BTW, I agree that dropping debian oldstable and Ubuntu's equivalent are acceptable - both currently only ship with Wesnot 1.10.
20160809 02:41:39< vultraz> then let us move travis *back* to 4.8
20160809 02:41:41< vultraz> :|
20160809 02:42:03< Aginor> let's put something about it on the mailing list so it's properly settled and archieved a bit better
20160809 02:42:17< Aginor> ideally with an analysis of the consequences
20160809 02:42:32< celticminstrel> ^
20160809 02:42:39< Aginor> and by "let's put" I mean "someone who's not me do it" :)
20160809 02:43:16 * vultraz curses get_states
20160809 02:43:18< celticminstrel> Preferably Vultraz. 
20160809 02:43:21< vultraz> what is this bullshit function
20160809 02:43:25 * vultraz takes break
20160809 02:45:07< vultraz> it boggles my mind that this shouldbe so complicated
20160809 02:45:14< vultraz> to do such a SIMPLE thing
20160809 02:45:23< celticminstrel> I still think get_states might be the wrong place to look.
20160809 02:46:08< vultraz> then where?
20160809 02:46:50< celticminstrel> Not quite sure yet.
20160809 02:47:41< celticminstrel> Okay, so I guess Debian oldstable may be the only one dropped by moving to 4.8.
20160809 02:48:00-!- travis-ci [~travis-ci@ec2-23-23-37-169.compute-1.amazonaws.com] has joined #wesnoth-dev
20160809 02:48:01< travis-ci> wesnoth/wesnoth#10236 (master - f56feea : Celtic Minstrel): The build was broken.
20160809 02:48:01< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/150814148
20160809 02:48:01-!- travis-ci [~travis-ci@ec2-23-23-37-169.compute-1.amazonaws.com] has left #wesnoth-dev []
20160809 02:48:09< vultraz> the way the gui1 dialog does it is check slowed, poisoned, petrified, and invisible individually
20160809 02:48:21< vultraz> and invisible has to be checked on the unit's current location...
20160809 02:48:24 * vultraz ;_;
20160809 02:48:32< celticminstrel> Lies...
20160809 02:48:47< celticminstrel> The build was already broken.
20160809 02:48:47< vultraz> 		if(i->invisible(i->get_location(),false))
20160809 02:48:49< vultraz> 			row << IMAGE_PREFIX << "misc/invisible.png";
20160809 02:48:50< vultraz> see?
20160809 02:49:02< celticminstrel> I wasn't responding to you there.
20160809 02:55:45< celticminstrel> Ugh, I can't see any good way to get custom statuses...
20160809 02:56:46< celticminstrel> I suppose you could obtain the reference to the game_lua_kernel and call luaW_getglobal("wesnoth", "theme_items", "unit_status"), though you'd need to ensure that the unit is "active" first (ie, would be shown in the sidebar)...
20160809 02:58:20< celticminstrel> I think it's probably fine to just do the main four statuses for now.
20160809 02:59:04< celticminstrel> It's better than not doing any, and it's better than listing every single status (since many statuses aren't meant to be shown).
20160809 03:02:02-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160809 03:03:41-!- jamit [~jamit@97-87-12-18.dhcp.mdsn.wi.charter.com] has left #wesnoth-dev []
20160809 03:05:29< vultraz> celticminstrel: any thoughts on that get_units thing?
20160809 03:26:45< celticminstrel> The get_shared_ptr is problematic.
20160809 03:26:57< celticminstrel> If you use a range-for, I don't see how you can get that effect.
20160809 03:27:17< celticminstrel> Maybe there's something like make_intrusive_ptr (or make_unit_ptr).
20160809 03:27:44< vultraz> but what if I don't use a shared_ptr?
20160809 03:27:59< celticminstrel> What do you intend to use instead?
20160809 03:28:42< vultraz> just a vector
20160809 03:29:05< celticminstrel> Vector of what?
20160809 03:29:27< vultraz> const_unit_ptr
20160809 03:29:28< irker320> wesnoth: Celtic Minstrel wesnoth:master 245ca6ce4020 / src/gui/widgets/listbox.hpp: Fix XCode 4 build https://github.com/wesnoth/wesnoth/commit/245ca6ce402097574006bc8ef71bd7a9d0232aa5
20160809 03:29:30< irker320> wesnoth: Celtic Minstrel wesnoth:master 414ef8530974 / .travis.yml: Travis: Stop using GCC 4.7 https://github.com/wesnoth/wesnoth/commit/414ef85309747a2c1bdf124daf6fbe0bbb926f3b
20160809 03:29:40< celticminstrel> Well, that's the problem.
20160809 03:32:56< celticminstrel> I suppose you could push_back cosnt_unit_ptr(&u)
20160809 03:37:00< celticminstrel> Since it's an intrusive_ptr
20160809 03:44:24< celticminstrel> Though that would be dangerous if it was ever changed to be a shared_ptr.
20160809 03:44:55< celticminstrel> You could also do a vector of bare unit*. I'm not sure if that can cause any problems.
20160809 03:53:03< vultraz> maybe I'll just leave it as-in
20160809 03:56:00< vultraz> or maybe i should construct it at the call site
20160809 03:56:06< vultraz> so I can display a message if there are no units
20160809 04:01:04< irker320> wesnoth: Charles Dang wesnoth:master 5b3c786e8ba9 / INSTALL: Mention GCC 4.8 and later instead of 4.7 https://github.com/wesnoth/wesnoth/commit/5b3c786e8ba965c732d5bb38e93616a40c4a88e9
20160809 04:01:07< irker320> wesnoth: Charles Dang wesnoth:master cfd205e3a46b / / (4 files in 3 dirs): Completed and activated the GUI2 Unit List dialog https://github.com/wesnoth/wesnoth/commit/cfd205e3a46b71ed1fb2db77c7a4fc76ec62e74c
20160809 04:08:15< vultraz> celticminstrel: is your compiler likely to choke on this http://pastebin.com/edit/Apq00ZvL
20160809 04:08:18< vultraz> without make_pair
20160809 04:09:11< celticminstrel> Bah.
20160809 04:09:24< celticminstrel> Lazy.
20160809 04:09:31< celticminstrel> ...okay fine.
20160809 04:10:14< celticminstrel> Not quite sure if it chokes on that, but I think it's likely.
20160809 04:10:22< celticminstrel> (Also, you posted the wrong link.)
20160809 04:10:27< celticminstrel> (Next time remove "edit".)
20160809 04:10:34< vultraz> oops
20160809 04:10:55 * vultraz also realized he could put the 'return' right on line 3
20160809 04:11:36< celticminstrel> I already forgot what that means.
20160809 04:12:01< vultraz> directly return instead of constructing the object and returning the object
20160809 04:12:20< celticminstrel> I dunno...
20160809 04:12:37< celticminstrel> I actually don't understand why there's still a STATE enum.
20160809 04:12:57< celticminstrel> Is it some intended optimization, or only a relic from when custom statuses didn't exist?
20160809 04:13:11< vultraz> where even is this enum
20160809 04:13:14< celticminstrel> Actually is it even an optimization?
20160809 04:13:18< celticminstrel> Probably in unit.hpp.
20160809 04:13:48< vultraz> oh yeah
20160809 04:13:51< vultraz> 	enum state_t { STATE_SLOWED = 0, STATE_POISONED, STATE_PETRIFIED,
20160809 04:13:52< vultraz> 		STATE_UNCOVERED, STATE_NOT_MOVED, STATE_UNHEALABLE, STATE_GUARDIAN, STATE_UNKNOWN = -1 };
20160809 04:14:12< vultraz> looks like a prime candidate for MAKE_ENUM
20160809 04:14:19< celticminstrel> No...
20160809 04:14:29< celticminstrel> Hmm.
20160809 04:14:37< celticminstrel> Maybe it is an optimizatino after all?
20160809 04:14:48< vultraz> (tangential: do scoped enums still only accept ints as integral types?)
20160809 04:14:51< celticminstrel> Is there any point in this optimization?
20160809 04:15:01< celticminstrel> I don't know what you're asking.
20160809 04:15:19< celticminstrel> Is it even an optimization, or is it just a relic? I could see it either way.
20160809 04:16:13< vultraz> eh
20160809 04:16:17< celticminstrel> (I could probably answer your question if I understood what you meant.)
20160809 04:16:33< vultraz> I guess the closest thing to MAKE_ENUM would be a struct
20160809 04:16:37< celticminstrel> I'm just wondering if there's any reason not to remove state_t.
20160809 04:16:44< celticminstrel> What are you asking about?
20160809 04:16:59< celticminstrel> I don't know what you mean by "scoped enums accept ints".
20160809 04:17:12< vultraz> I'm wondering if there's any close equivalent to what we do with MAKE_ENUM in the stdlib
20160809 04:17:25< vultraz> and I have concluded it would be a struct
20160809 04:17:31< celticminstrel> There isn't, and never will be.
20160809 04:17:32< vultraz> because I don't think
20160809 04:17:51< vultraz> enum class foo { a = "a string" }; will ever be valid
20160809 04:18:02< celticminstrel> At least, I hope there never will be. It's not something suitable for the standard library.
20160809 04:18:10< celticminstrel> Yeah, that'll never be valid either.
20160809 04:18:25< celticminstrel> It's not valid in any language really.
20160809 04:18:34< celticminstrel> (Any language that has enum types.)
20160809 04:18:44< celticminstrel> (I suppose SQL enums are strings actually.)
20160809 04:18:54< celticminstrel> (Don't remember if that's standard or an extension.)
20160809 04:20:52-!- JyrkiVesterinen [~JyrkiVest@87-100-255-227.bb.dnainternet.fi] has joined #wesnoth-dev
20160809 04:22:18< vultraz> anyway
20160809 04:22:23< vultraz> does it build?
20160809 04:22:59< vultraz> and I'm guessing state_t exists because multiple functions take states as arguments
20160809 04:23:19< celticminstrel> Well yes, but that could be changed.
20160809 04:23:30< vultraz> to?
20160809 04:23:58< celticminstrel> String states. Custom states are already strings.
20160809 04:24:24< celticminstrel> So built-in statuses are currently stored in a separate container from the custom ones.
20160809 04:24:56< vultraz> sounds like a relic, then
20160809 04:25:21< vultraz> and makes it impossible to get custom statuses
20160809 04:25:27< celticminstrel> Huh?
20160809 04:25:38< celticminstrel> No it doesn't.
20160809 04:25:56< vultraz> oh wait
20160809 04:26:00< vultraz> set and get_state are overloaded
20160809 04:26:03< vultraz> with string arguments
20160809 04:26:07< vultraz> and t_state
20160809 04:26:09< celticminstrel> Yes.
20160809 04:26:12< celticminstrel> state_t
20160809 04:26:24< vultraz> right
20160809 04:26:54< vultraz> i guess it's so there's a list of builtin statuses?
20160809 04:27:13< vultraz> and it's a littler easier to read the code
20160809 04:27:39< celticminstrel> How is it easier to read the code?
20160809 04:27:48< celticminstrel> I suppose there could be some slight advantage in having the list...
20160809 04:27:53< vultraz> since you know what state it's talking about
20160809 04:28:06< vultraz> also with state_t, you can then do this
20160809 04:28:09< celticminstrel> You'd know that with string states, too.
20160809 04:28:10< vultraz> return known_boolean_states_[state];
20160809 04:28:25< celticminstrel> With string states, can't you just return state?
20160809 04:28:56< vultraz> well, the point of the map is a string/string name/ "yes" pair
20160809 04:29:14< celticminstrel> Huh?
20160809 04:30:00< vultraz> std::map<std::string, unit::state_t>
20160809 04:30:06< vultraz> the string is "yes"
20160809 04:30:15< celticminstrel> ...huh?
20160809 04:30:27< vultraz> so basically states are flagged in a map with "yes" if they're valid
20160809 04:30:39< vultraz> this sounds very suboptimal 
20160809 04:30:44< celticminstrel> Where the heck are you getting "yes" from?
20160809 04:31:24< vultraz> in get_states()
20160809 04:31:26< vultraz> 	for (std::string const &s : states_) {
20160809 04:31:28< vultraz> 		all_states[s] = "yes";
20160809 04:31:30< vultraz> 	}
20160809 04:31:52< vultraz> oh wait
20160809 04:31:58< vultraz> im a little mixed up..
20160809 04:32:12< vultraz> ...
20160809 04:32:15< vultraz> ok now I have no idea
20160809 04:32:35< vultraz> what is states_..
20160809 04:32:37< vultraz> std::set<std::string> 
20160809 04:32:54< vultraz> we also have..
20160809 04:32:56< vultraz> 	std::vector<bool> known_boolean_states_;
20160809 04:32:57< vultraz> 	static std::map<std::string, state_t> known_boolean_state_names_;
20160809 04:33:02< vultraz> celticminstrel: can you make any sense of this :|
20160809 04:33:11< celticminstrel> I'm guessing get_states() returns a config?
20160809 04:34:14< vultraz> no
20160809 04:34:17< vultraz> a std::map<std::string,std::string>
20160809 04:34:40< celticminstrel> I see...
20160809 04:35:30< celticminstrel> known_boolean_states_ is just the built-in states.
20160809 04:35:47< celticminstrel> known_boolean_state_names_ maps the string name to the corresponding state_t.
20160809 04:36:48< vultraz> I think
20160809 04:36:56< vultraz> MAKE_ENUM would be usful
20160809 04:36:58< vultraz> useful
20160809 04:37:02< celticminstrel> Looking up a state in the vector<bool> is definitely faster than looking up a string state... though not sure if that difference is relevant...
20160809 04:37:12< celticminstrel> MAKE_ENUM would complicate things here.
20160809 04:37:35< celticminstrel> Though I suppose its built-in string-enum mapping could be useful...
20160809 04:37:53< celticminstrel> I'm still questioning the need for a state_t at all.
20160809 04:38:23< celticminstrel> Lookup for a string state should be O(log n), compared to O(1) for the boolean state...
20160809 04:38:48< celticminstrel> n here is tht total number of states currently set.
20160809 04:38:51< celticminstrel> ^the
20160809 04:39:02< celticminstrel> Which in practice probably won't exceed 10 or so, right?
20160809 04:40:30< vultraz> less, I'd say
20160809 04:40:30< vultraz> no more than 5
20160809 04:40:30< vultraz> but 10 I guess is more realisic
20160809 04:40:32< vultraz> given all possible ones
20160809 04:40:57< celticminstrel> I'm not quite sure how many states there are.
20160809 04:41:07< celticminstrel> Excluding the boolean ones, there's at least four.
20160809 04:41:22< celticminstrel> Seven boolean ones.
20160809 04:41:45< vultraz> undrainable, unpoisonable, unplagueable, and (possibly deprecated) not_living
20160809 04:42:01< celticminstrel> Dunno if there are others, but that's already 11 if you were to remove state_t.
20160809 04:42:20< celticminstrel> Still, even if there were 100 it wouldn't make all that much difference, because logarithm.
20160809 04:49:00< vultraz> btw, not_living was split in 2012
20160809 04:49:23< celticminstrel> What about it?
20160809 04:50:28< vultraz> dunno if it was deprecated then too
20160809 05:02:24< vultraz> celticminstrel: so how do you recommend I refactor this
20160809 05:02:33< celticminstrel> I dunno.
20160809 05:03:09< celticminstrel> It would help to understand how often statuses are checked in, say, AI code.
20160809 05:05:16< vultraz> 5 times
20160809 05:05:39< celticminstrel> 5 instances ≠ 5 times
20160809 05:05:44< vultraz> in the moveto and find village stuff
20160809 05:05:50< celticminstrel> Hmm...
20160809 05:06:06< celticminstrel> They should be checked in attack too...
20160809 05:06:09< vultraz> and attack analysis
20160809 05:06:18< vultraz> keep in mind this is get_state(
20160809 05:06:21< vultraz> not get states()
20160809 05:06:30< celticminstrel> Right.
20160809 05:09:36< celticminstrel> Attack analysis in particular is called many times per turn.
20160809 05:10:12< vultraz> eh, alright
20160809 05:10:13< celticminstrel> If I'm not mistaken, it's called for every pair of units that could potentially engage on that turn.
20160809 05:10:24< vultraz> I'll just do some cleanup on the existing code 
20160809 05:10:41-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160809 05:10:47< celticminstrel> I'm not really sure how much difference the O(1) get_state would have over the O(log n) state in this situation.
20160809 05:10:50< vultraz> ah, ancestral!
20160809 05:10:59< ancestral> ah, vultraz!
20160809 05:11:07< vultraz> ancestral: I have a report that the posted sha215 for the macOS package doesn't match the download
20160809 05:11:10< vultraz> can you confirm?
20160809 05:11:22< ancestral> sha215?
20160809 05:11:28< celticminstrel> Without properly considering this I think it's probably not good to remove state_t altogether; and I'm leery of turning it into a MAKE_ENUM as well since it's basically used as an index into known_boolean_states_.
20160809 05:11:44< vultraz> 256
20160809 05:11:58< ancestral> Alright let’s see
20160809 05:12:12< ancestral> (It could be I uploaded the wrong file)
20160809 05:12:16< ancestral> (sha file)
20160809 05:13:05-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Client Quit]
20160809 05:15:11-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Remote host closed the connection]
20160809 05:16:07-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160809 05:19:04< vultraz> ok, so get_states is basically get_all_states
20160809 05:19:21< celticminstrel> Yes.
20160809 05:19:30< celticminstrel> Though in a very bizarre format.
20160809 05:19:38< vultraz> yes
20160809 05:19:41< celticminstrel> Out of curiosity, how often is it called?
20160809 05:20:09< vultraz> once in unit.cpp
20160809 05:20:15< vultraz> once in units/filter.cpp
20160809 05:20:30< vultraz> and once in formula/callable_objects.cpp
20160809 05:20:36< celticminstrel> What's the first case?
20160809 05:20:46< celticminstrel> Huh, so it's not called in game_lua_kernel.cpp?
20160809 05:21:00< vultraz> nein
20160809 05:21:15< celticminstrel> Oh, right, unit statuses use a metatable, so it doesn't need to fetch all of them at once.
20160809 05:21:22< vultraz> first case is in unit::write
20160809 05:21:45< celticminstrel> Ah, makes sense, though doesn't it need a config for that?
20160809 05:21:51< vultraz> 	std::map<std::string,std::string> all_states = get_states();
20160809 05:21:52< vultraz> 	for(std::map<std::string,std::string>::const_iterator st = all_states.begin(); st != all_states.end(); ++st) {
20160809 05:21:54< vultraz> 		status_flags[st->first] = st->second;
20160809 05:21:55< vultraz> 	}
20160809 05:21:58< celticminstrel> Bleh.
20160809 05:22:23< vultraz> the second case is used for filtering
20160809 05:22:30< celticminstrel> Obviously.
20160809 05:22:36< vultraz> last case is in unit_callable::get_value
20160809 05:22:49< celticminstrel> Obviously.
20160809 05:23:06< celticminstrel> Hmm. That's actually pretty dumb, isn't it?
20160809 05:23:14< vultraz> this whole "yes" stuff is annoying me.
20160809 05:23:29< celticminstrel> I think we can pretty much remove get_states().
20160809 05:23:46< celticminstrel> Move its code into unit::write, but put them in a config in the first place.
20160809 05:24:01< celticminstrel> Hmm.
20160809 05:24:23< vultraz> we still need a way to get a list of currently applied states
20160809 05:25:16< vultraz> without this "yes" bullshit
20160809 05:25:25< celticminstrel> Well, if you want to keep get_states(), make it return a std::set<std::string>.
20160809 05:25:51< celticminstrel> Then all it has to do is make a copy of states_, and add any boolean states.
20160809 05:26:31< celticminstrel> Or I can do this.
20160809 05:26:33< vultraz> aren't all states boolean, tho?
20160809 05:26:46< celticminstrel> Yes, that's why it can be a std::set instead of a std::map.
20160809 05:27:02< vultraz> er, what's a set?
20160809 05:27:22< celticminstrel> Mathematical set. No duplicates, unspecified order.
20160809 05:27:30< celticminstrel> (In fact a std::set is always sorted.)
20160809 05:29:46 * celticminstrel has started doing it now.
20160809 05:29:54 * celticminstrel can stop if you want though.
20160809 05:30:16-!- hay207 [~hay207@41.34.13.116] has quit [Quit: Konversation terminated!]
20160809 05:30:32< vultraz> go ahead
20160809 05:30:40< vultraz> I'll do something else
20160809 05:30:53-!- Kwandulin [~Miranda@p200300760F35BFDB102457CCB98A788A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160809 05:31:06< celticminstrel> I'm only touching get_states, not the other state stuff.
20160809 05:31:45< vultraz> include that thing I gave you in the paste, if it builds
20160809 05:31:58< celticminstrel> I forgot what that was...
20160809 05:32:57< vultraz> celticminstrel: http://pastebin.com/Apq00ZvL
20160809 05:37:23-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160809 05:38:17-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160809 05:40:39< ancestral> vultraz: Should be cc0bb33c480a0ae01ce49aa52efc310347a483d7191ed17f2b789a885612c96e
20160809 05:40:44< ancestral> Is that the file on the web site?
20160809 05:42:01< ancestral> It is
20160809 05:42:12< vultraz> It is
20160809 05:42:16< vultraz> I confirmed in all three places
20160809 05:42:33< ancestral> Alright, I guess I’ll download the dmg then
20160809 05:49:04< ancestral> Okay the file is different
20160809 05:49:14< ancestral> Guess I’ll reupload
20160809 05:51:44< vultraz> ancestral: or just update the checksum?
20160809 05:51:49< celticminstrel> It's funny to see the build fail with no errors.
20160809 05:52:01< ancestral> I’m not convinced this is the right version
20160809 05:52:21< celticminstrel> What's different between them?
20160809 05:52:43< ancestral> Probably a fix you helped me make with 10.7 compatability
20160809 05:53:30< celticminstrel> Maybe PCRE?
20160809 05:53:37< ancestral> Yeah
20160809 05:53:46< celticminstrel> The uploaded version lacks it?
20160809 05:54:13< ancestral> Hmm, well
20160809 05:54:23< celticminstrel> Or something else?
20160809 05:54:39< ancestral> I see it in both versions
20160809 05:55:04< celticminstrel> Okay, are there any files that are not in both versions?
20160809 05:55:20< celticminstrel> I guess you don't need to check all the data folders, but besides that...
20160809 05:56:16< ancestral> I’m diffing, could take a while
20160809 05:56:18< ancestral> And reuploading
20160809 05:56:56< ancestral> diff is 0 bytes
20160809 05:57:14< ancestral> So they just randomly have a different checksum
20160809 05:57:22< ancestral> Well, I’m reuploading
20160809 05:57:30< ancestral> 7 minutes ETA
20160809 05:58:24< ancestral> Okay, technically I didn’t diff the entire dmg, just the app
20160809 05:58:36< ancestral> So maybe one has like a different setting for the size of the window or something
20160809 05:59:50< celticminstrel> vultraz: I think your pastebin thing isn't actually a good idea. If I understand correctly, it would construct a new copy of the map on every call. Though, the current implementation is no better...
20160809 06:00:12< vultraz> celticminstrel: known_boolean_state_names_ is static in the header
20160809 06:00:19< vultraz> which seems weird..
20160809 06:00:41< vultraz> since it's only called in-class
20160809 06:00:52< celticminstrel> Oh wait, maybe get_known_boolean_state_names is only ever called once?
20160809 06:00:52< vultraz> it should be moved entirely to the .cpp
20160809 06:02:16< vultraz> yes, to populate known_boolean_state_names_ in the constructor
20160809 06:02:26< vultraz> this is stupid :|
20160809 06:02:41< celticminstrel> No, that's not what it's used for in the constructor.
20160809 06:03:05< celticminstrel> It's used to initialize the known_boolean_states_ vector to the correct length.
20160809 06:03:15< celticminstrel> Or bitset really.
20160809 06:03:27< celticminstrel> vector<bool> is a dynamic-sized bitset.
20160809 06:03:59< celticminstrel> The conclusion I've come to is that the function isn't really needed.
20160809 06:04:05< JyrkiVesterinen> Suggestion. How about bumping the minimum GCC version to 4.8.1?
20160809 06:04:20< JyrkiVesterinen> GCC 4.8.1 has full support for C++11 language features, unlike 4.8.0.
20160809 06:04:21< JyrkiVesterinen> https://isocpp.org/blog/2013/05/gcc-4.8.1-released-c11-feature-complete
20160809 06:04:40< iceiceice> JyrkiVesterinen, that's not really true,
20160809 06:04:42< celticminstrel> Probably not much point. We can't fully support C++11 because of MSVC, right?
20160809 06:04:44< JyrkiVesterinen> I believe pretty much no one is on 4.8.0 today.
20160809 06:04:44< iceiceice> it has experimental support for C++11
20160809 06:05:05< vultraz> celticminstrel: if it's not needed, remove it
20160809 06:05:06< iceiceice> and several nontrivail bugs
20160809 06:05:09< celticminstrel> Unless those extra C++11 features it supports are also supported by MSVC.
20160809 06:05:23 * vultraz curses MSVC
20160809 06:05:32< celticminstrel> MSVC 2013, to be precise.
20160809 06:05:56< celticminstrel> If I absolutely have to I can probably use a newer compiler.
20160809 06:06:10< JyrkiVesterinen> Based on this page I can see one feature we'd gain: decltype version 1.1.
20160809 06:06:10< JyrkiVesterinen> http://en.cppreference.com/w/cpp/compiler_support
20160809 06:06:33< JyrkiVesterinen> MSVC gained support in MSVC2012, GCC in v4.8.1.
20160809 06:06:35< iceiceice> i think the best way to determine if you have "full" support is to look in the compiler documentation
20160809 06:06:48< iceiceice> if they characterize it as "experimental" in big bold letters, that means it is experimental.
20160809 06:06:51< celticminstrel> We're already using decltype...
20160809 06:06:57< iceiceice> if when you type gcc -v, it says "experimental"
20160809 06:07:04< iceiceice> that means it is experimental.
20160809 06:07:17< JyrkiVesterinen> celticminstrel: Yes, version 1.0. Supported since GCC 4.3.
20160809 06:07:18< celticminstrel> In six places, to be precise.
20160809 06:07:22< celticminstrel> Ah.
20160809 06:08:13< ancestral> Done
20160809 06:08:16< ancestral> Now re-downloading…
20160809 06:11:12< celticminstrel> I don't know the difference between decltype 1.0 and decltype 1.1.
20160809 06:11:26< celticminstrel> Was the older just a clone of typeof or something?
20160809 06:12:19< ancestral> vultraz: Well, I can’t explain it
20160809 06:12:46< ancestral> SF’s copy has a different SHA after I upload via SFTP
20160809 06:12:51< vultraz> huh
20160809 06:13:05< celticminstrel> Weird.
20160809 06:13:05< ancestral> I could change everything to that SHA, if we can trust it
20160809 06:13:12< celticminstrel> Try a full diff maybe?
20160809 06:13:15< ancestral> Or I can try uploading via a different method
20160809 06:13:17< celticminstrel> Just in case?
20160809 06:13:18< ancestral> diff -ru?
20160809 06:13:25< ancestral> I did on the app
20160809 06:13:29< ancestral> I’ll try the whole .dmg
20160809 06:13:53< celticminstrel> I was thinking the contents of the mounted .dmg rather than the .dmg itself, but I suppose either works...
20160809 06:14:07< celticminstrel> The former is more likely to give useful information though, I'd think.
20160809 06:14:59< ancestral> zero bytes
20160809 06:15:01< JyrkiVesterinen> celticminstrel: Yes, I think decltype v1.1 was only a minor improvement. It's not important at all.
20160809 06:15:07< ancestral> Okay
20160809 06:15:23< celticminstrel> ancestral: So there's no difference in the content...
20160809 06:15:27< JyrkiVesterinen> I was just thinking that we could just as well go for 4.8.1 if we can require 4.8.0.
20160809 06:16:25< ancestral> Doing diff on the contents of the mounted dmgs
20160809 06:16:35< ancestral> Might take a while
20160809 06:16:50< celticminstrel> How can the SHA be different if the files are byte-for-byte identical...
20160809 06:17:22< ancestral> $ sudo diff -ru /Volumes/Wesnoth\ 1.13.5\ 1/ /Volumes/Wesnoth\ 1.13.5/ > ~/Desktop/differences.diff
20160809 06:17:30< ancestral> And that file is 0 bytes
20160809 06:17:54< celticminstrel> Still, if they really are identical in every way, I suppose it's probably safe to update with the SHA of the downloaded version?
20160809 06:17:59< ancestral> The only thing I can think of is SFTP is messing something up?
20160809 06:18:01< celticminstrel> The diff does include invisible files, right?
20160809 06:18:18< ancestral> I don’t know diff well enough
20160809 06:18:26< celticminstrel> Oh right, if you diffed the dmg file itself, then it would include everything for sure...
20160809 06:18:34< ancestral> If sf.net can be trusted, sure, we can change it
20160809 06:18:41< ancestral> celticminstrel: Already did diff the file
20160809 06:18:45< celticminstrel> Unless it's partially in the resource fork...
20160809 06:18:51< celticminstrel> (Or other extended attributes)
20160809 06:18:52< ancestral> I guess I could sha the contents
20160809 06:19:01< ancestral> Yeah, fork or atts
20160809 06:19:06< ancestral> Would SFTP not copy that stuff?
20160809 06:19:11< celticminstrel> But, I wouldn't expect that, given how dmg is considered the standard for distributing files.
20160809 06:19:16< ancestral> Will revisit in the morning
20160809 06:19:23-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160809 06:19:49< celticminstrel> I was about to suggest stripping xattrs from a copy of the local dmg and seeing if that produces the same SHA as the downloaded one.
20160809 06:21:00< celticminstrel> I wouldn't expect SFTP to copy xattrs, though maybe it would if it could prove that the remote host supports them. (Which sf, and most others, presumably wouldn't.)
20160809 06:27:01-!- midzer [~quassel@p57B4551A.dip0.t-ipconnect.de] has quit [Quit: No Ping reply in 180 seconds.]
20160809 06:28:08-!- midzer [~quassel@p57B4551A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160809 06:39:18< irker320> wesnoth: Celtic Minstrel wesnoth:master 47575c6a4480 / src/ (formula/callable_objects.cpp units/filter.cpp units/unit.cpp units/unit.hpp): Some cleanup of unit status code https://github.com/wesnoth/wesnoth/commit/47575c6a44808fe50df9c75c39d3ec7417a95adb
20160809 06:39:20< irker320> wesnoth: Celtic Minstrel wesnoth:master c401f2db15d8 / src/formula/callable_objects.cpp: Some cleanup of formula callable code - mainly auto, range-for https://github.com/wesnoth/wesnoth/commit/c401f2db15d8f90d8e9a720fa47bd4e301e0f5f4
20160809 06:39:42< vultraz> you know you could remove convert_map
20160809 06:40:14< celticminstrel> Maybe.
20160809 06:40:25< celticminstrel> It feels like something that could be useful though.
20160809 06:43:05< vultraz> still, this is good cleanup
20160809 06:44:06-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160809 07:04:28-!- travis-ci [~travis-ci@ec2-23-23-37-169.compute-1.amazonaws.com] has joined #wesnoth-dev
20160809 07:04:29< travis-ci> wesnoth/wesnoth#10247 (master - 414ef85 : Celtic Minstrel): The build was fixed.
20160809 07:04:29< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/150821995
20160809 07:04:29-!- travis-ci [~travis-ci@ec2-23-23-37-169.compute-1.amazonaws.com] has left #wesnoth-dev []
20160809 07:06:47< vultraz> hmm
20160809 07:06:56< vultraz> for the recall dialog, I think the shared_ptr bit can be removed.
20160809 07:06:59< vultraz> for the unit list..
20160809 07:07:18< vultraz> you said we didn't need get_shared ptr, tho?
20160809 07:07:42< celticminstrel> I don't think I said that.
20160809 07:09:10< vultraz> you said const_unit_ptr(&u) could be used or something
20160809 07:09:15< vultraz> but would be dangerous
20160809 07:09:39< celticminstrel> It's not dangerous. However, if const_unit_ptr was later changed to be a shared_ptr instead of an intrusive_ptr, it would become dangerous.
20160809 07:11:36< vultraz> why?
20160809 07:12:52< celticminstrel> If you construct a shared_ptr from an existing pointer, then when that shared_ptr leaves scope, the pointer will be destroyed. That means that anything else referring to that pointer is now pointing at unallocated space. In this specific case, it would mean that there are pointers in the unit map pointing to units that no longer exist.
20160809 07:14:00< celticminstrel> In fact, pushing const_unit_ptr(&u) in that place would wipe out the entire unit map if const_unit_ptr were a shared_ptr... but leave all the dangling pointers in the map.
20160809 07:14:20< celticminstrel> It wouldn't wipe it until the dialog closed, I think... but still.
20160809 07:18:03< vultraz> are we planning on making it a shared_ptr?
20160809 07:18:32< celticminstrel> Not to my knowledge.
20160809 07:18:44< vultraz> is there any reason to do so?
20160809 07:18:51< celticminstrel> Not particularly.
20160809 07:19:12< vultraz> it would get rid of the ugly, ugly custom refcounting
20160809 07:19:30< celticminstrel> It's not really that ugly, is it?
20160809 07:19:35< vultraz> it is
20160809 07:19:42< iceiceice> vultraz, there are much uglier things to worry about :p
20160809 07:19:44< celticminstrel> I don't see why?
20160809 07:19:51< vultraz> I don't know why
20160809 07:19:55< vultraz> but it is
20160809 07:20:18< iceiceice> i agree that custom ref counting is fairly ugly,
20160809 07:20:24< iceiceice> std::shared_ptr also has some drawbacks
20160809 07:20:35< iceiceice> and this code is mostly working to my knowledge
20160809 07:20:49< iceiceice> i mean there are actual bugs
20160809 07:21:10< iceiceice> usually changing stuff that is working is considered undesirable
20160809 07:21:42< iceiceice> if you want to get rid of boost includes, i guess you could try to roll your own `intrusive_ptr`
20160809 07:21:53< iceiceice> but i guess that's fairly quixotic
20160809 07:22:41< iceiceice> idk
20160809 07:22:51< irker320> wesnoth: Charles Dang wesnoth:master e750b5851952 / src/ (gui/dialogs/unit_recall.cpp gui/dialogs/unit_recall.hpp menu_events.cpp): Don't use a shared_ptr for recall list handling https://github.com/wesnoth/wesnoth/commit/e750b5851952b3f9ea947ef740c7fda6c4300778
20160809 07:22:53< iceiceice> maybe it is simpler to just use shared_ptr everywhere
20160809 07:24:10< celticminstrel> Basically what iceiceice said. "Don't fix what's not broken"
20160809 07:24:39-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160809 07:24:47< vultraz> wonder if I really needed to get rid of all those at()s
20160809 07:28:06-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Client Quit]
20160809 07:28:20-!- Kwandulin [~Miranda@p200300760F35BFDB102457CCB98A788A.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160809 07:28:36-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has joined #wesnoth-dev
20160809 07:28:43< celticminstrel> at() is theoretically slower than []
20160809 07:28:48< celticminstrel> Not sure if that really matters though
20160809 07:29:02< celticminstrel> The difference is probably negligible in most cases.
20160809 07:29:34-!- Kwandulin [~Miranda@p200300760F35BF10102457CCB98A788A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160809 07:29:49< JyrkiVesterinen> On the other hand, at() protects you from out-of-bounds access.
20160809 07:30:07< celticminstrel> Yes, that's why it's theoretically slower.
20160809 07:30:08< JyrkiVesterinen> (Or, more accurately, is guaranteed to crash if you do that.)
20160809 07:30:23< celticminstrel> Technically not a crash - it's an exception, so you can catch it.
20160809 07:31:53< vultraz> why does get_units() need to return a unit_map..
20160809 07:31:56< vultraz> let us see..
20160809 07:33:01< vultraz> I see
20160809 07:33:14-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160809 07:33:57< vultraz> hmm hmm
20160809 07:33:59< vultraz> "By popular demand iterators are effectively permanent. They are handles and not iterators."
20160809 07:35:57-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Client Quit]
20160809 07:36:12< iceiceice> vultraz, the unit_map is basically its own little reference counting system also
20160809 07:36:20< vultraz> ;|
20160809 07:36:48< vultraz> I guess I'll just leave the unit list with the shared_ptr
20160809 07:36:53< vultraz> I can't really remove it
20160809 07:36:56-!- travis-ci [~travis-ci@ec2-54-234-99-17.compute-1.amazonaws.com] has joined #wesnoth-dev
20160809 07:36:57< travis-ci> wesnoth/wesnoth#10248 (master - cfd205e : Charles Dang): The build has errored.
20160809 07:36:57< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/150826270
20160809 07:36:57-!- travis-ci [~travis-ci@ec2-54-234-99-17.compute-1.amazonaws.com] has left #wesnoth-dev []
20160809 07:39:13< celticminstrel> The get_shared_ptr function doesn't actually return a shared_ptr, I'm pretty sure.
20160809 07:39:35< vultraz> where is it defined anyway
20160809 07:39:47< celticminstrel> Probably units/map.hpp
20160809 07:40:06< vultraz> ah
20160809 07:40:08< vultraz> " // This is exactly the same as operator-> but it's slightly more readable, and can replace &*iter syntax easily."
20160809 07:41:18< vultraz> wait
20160809 07:41:19< vultraz> ..
20160809 07:44:16< vultraz> Just realized I'm sitting here complaining about the shared_ptr when I actually don't need it at all because I got it mixed up with get_shared_ptr :|
20160809 07:45:48< irker320> wesnoth: Charles Dang wesnoth:master cf1d2e3c83d3 / src/gui/dialogs/ (unit_list.cpp unit_list.hpp): Don't use a shared_ptr in Unit List dialog https://github.com/wesnoth/wesnoth/commit/cf1d2e3c83d33fe236b0ddf0d2229001700fb1a9
20160809 07:46:01< vultraz> why didn't you say this earlier
20160809 07:46:57< celticminstrel> Didn't I just say that get_shared_ptr doesn't return a shared_ptr?
20160809 07:47:03< vultraz> yes
20160809 07:47:09< vultraz> why didn't you say that earlier
20160809 07:47:18< celticminstrel> I have no idea.
20160809 07:47:32< celticminstrel> It just didn't seem relevant or something?
20160809 07:49:32< vultraz> god, the display_context class is so random..
20160809 07:49:41< celticminstrel> Huh?
20160809 07:50:19< vultraz> seems like all (or most of) this stuff would be better in other class
20160809 07:50:34< celticminstrel> Why?
20160809 07:50:50-!- celticminstrel is now known as celmin|sleep
20160809 07:51:12< vultraz> oh my god an actual use of const_cast! :O
20160809 07:51:19< celmin|sleep> ...oh my it's ten to four.
20160809 07:51:23< celmin|sleep> Huh? Where?
20160809 07:51:53< vultraz> ...
20160809 07:52:04< vultraz> turns out there are actually 59 uses of const_cast in the codebase :|
20160809 07:53:04< JyrkiVesterinen> It's 59 too many. Const_cast is a huge code smell. :(
20160809 07:53:06< celmin|sleep> Some of them may be unavoidable.
20160809 07:53:28< celmin|sleep> src/ai/lua/core.cpp:62 seems like one maybe
20160809 07:54:06< celmin|sleep> And others in that file...
20160809 07:54:13< vultraz> (also, we should look at what this custom smart_list does)
20160809 07:54:15< celmin|sleep> Not sure... why is it needed there...
20160809 07:56:25< iceiceice> celmin|sleep, that is definitely not needed
20160809 07:56:27< vultraz> (looks like a list where nothing ever actually removed)
20160809 07:56:32< iceiceice> in lua/core.cpp
20160809 07:56:35< iceiceice> its just someone being lazy
20160809 07:56:44< celmin|sleep> Well, aisKey could be changed to be non-const I guess.
20160809 07:56:50< celmin|sleep> Though it's logically const.
20160809 07:57:23< iceiceice> there are ltos of ways to make a unique key for lua registry that don't involve const cast
20160809 07:57:26< iceiceice> *lots of ways
20160809 07:57:38< celmin|sleep> Wesnoth uses two or three different ways.
20160809 07:58:01< JyrkiVesterinen> Here is the only use of smart_list: https://github.com/wesnoth/wesnoth/blob/cf1d2e3c83d33fe236b0ddf0d2229001700fb1a9/src/game_events/handlers.hpp#L90
20160809 07:58:24< celmin|sleep> lua_types.cpp uses the same method (involving a const_cast) but hides it better.
20160809 07:58:43< vultraz> JyrkiVesterinen: yes, I've found that
20160809 07:59:13< vultraz> I have no idea if there's a better way to do such a thing now, though.
20160809 08:00:03< celmin|sleep> I have no idea what it even is.
20160809 08:00:20< vultraz>  /// This is a variant on a list that never invalidates iterators (unless, of
20160809 08:00:21< vultraz>  /// course, the list ceases to exist). In particular, an erase() will only flag
20160809 08:00:23< vultraz>  /// an element for removal from the list. Flagged elements are ignored by list
20160809 08:00:24< vultraz>  /// functions, but they still exist from the perspective of iterators that had
20160809 08:00:25< vultraz>  /// pointed (and still point) to the element.
20160809 08:00:44< celmin|sleep> Ah. Why does it need that?
20160809 08:00:44< vultraz> doesn't sound very "smart" at all :P
20160809 08:01:00< celmin|sleep> Also, that sounds like it would slowly fill up with removed elements.
20160809 08:01:26< vultraz> indeed
20160809 08:01:41< celmin|sleep> Why does it need iterators for deleted elements to remain valid? That doesn't make sense.
20160809 08:01:47< iceiceice> when wesnoth was written many of the devs didn't ike iterator invalidation rules
20160809 08:02:11< iceiceice> they just wanted it to be simple so that people who barely know C++ can work on the code
20160809 08:02:15< celmin|sleep> It's not like this is Java where iterators are automatically invalidated any time the container is changed.
20160809 08:02:31< vultraz> const_iterator begin() const           { return iterator(const_cast<list_t &>(data_).begin()); }
20160809 08:02:34 * vultraz cringessss
20160809 08:02:45< celmin|sleep> Iterators in C++ containers are evaluated exactly when they need to be invalidated.
20160809 08:02:59< vultraz> let us ask gfgtdf later
20160809 08:03:10< vultraz> this is in the event code, so he might know
20160809 08:03:14< iceiceice> yeah but if you don't understand how the container works under the hood, you don't know when that is, do you?
20160809 08:03:32< celmin|sleep> It's specified by the standard, more or less.
20160809 08:03:40< iceiceice> yeah but most wesnoth developers never looked at the standard
20160809 08:03:44< celmin|sleep> You may not know exactly when they'll be invalidated.
20160809 08:03:56< vultraz> celmin|sleep: get some sleep
20160809 08:04:04< celmin|sleep> But you can set things up so that you know they won't be - for example, using set_capacity in a vector.
20160809 08:04:07< vultraz> tomorrow we can clean up const_casts :D
20160809 08:04:10< celmin|sleep> And I'm actually going to live up to my nick now. >_>
20160809 08:04:24< celmin|sleep> I feel like smart_list is a bad idea that should be removed, but needs a closer look.
20160809 08:04:42< vultraz> it's only used in one place, which is good
20160809 08:06:20< vultraz> might also be able to remove shared_object, which doesn't seem to be used anywhere
20160809 08:09:43< vultraz> iterator_extend also looks dirty
20160809 08:10:37-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Quit: Ex-Chat]
20160809 08:11:59< vultraz>  /// This is an iterator class that extends an existing iterator by overriding
20160809 08:12:00< vultraz>  /// dereference. Access to the underlying iterator is controlled, promoting 
20160809 08:12:02< vultraz>  /// a black-box approach.
20160809 08:12:05< vultraz> why would one need such a thing
20160809 08:15:06-!- celmin|sleep [~celmin@unaffiliated/celticminstrel] has quit [Ping timeout: 258 seconds]
20160809 08:17:13< JyrkiVesterinen> Well, iterator_extend looks like a fairly powerful class that can be used for some tricks.
20160809 08:17:32< JyrkiVesterinen> Deref::eval() could, for example, log iterator defererences.
20160809 08:17:51< JyrkiVesterinen> I could imagine that being used for performance analysis or something.
20160809 08:18:27< JyrkiVesterinen> Or it could throw an exception if it's about to return a value that the caller isn't supposed to see.
20160809 08:18:42< JyrkiVesterinen> Hmm, none of the uses I can come up with make much sense...
20160809 08:22:49-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160809 08:27:32< vultraz> gonna work on the Status dialog next
20160809 09:04:00-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160809 09:06:27-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 264 seconds]
20160809 09:06:28-!- wedge010 is now known as wedge009
20160809 09:28:19-!- vincent_c [~bip@vcheng.org] has quit [Ping timeout: 260 seconds]
20160809 09:38:55-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20160809 09:43:09-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160809 10:06:41-!- vincent_c [~bip@vcheng.org] has quit [Quit: Coyote finally caught me]
20160809 10:07:12-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20160809 10:11:18-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160809 10:23:54-!- Kwandulin [~Miranda@p200300760F35BF10102457CCB98A788A.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160809 10:38:31-!- fabi__ [~fabi@176.5.34.179] has joined #wesnoth-dev
20160809 10:41:29-!- fabi_ [~fabi@176.5.136.236] has quit [Ping timeout: 258 seconds]
20160809 10:45:52-!- irker320 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160809 10:55:42< Aginor> ancestral: I wouldn't trust the sf.net sha
20160809 11:03:14-!- gfgtdf [~chatzilla@x4e36a72a.dyn.telefonica.de] has joined #wesnoth-dev
20160809 11:05:42-!- Kwandulin [~Miranda@p200300760F35BF103885105974259480.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160809 11:06:31< vultraz> gfgtdf: do you know why game_events::handler_list needs to use smart_list?
20160809 11:09:02< gfgtdf> vultraz: from the comments i'd guess trhat's so that we dont have to worry when we remove elements while iterating over that list
20160809 11:10:03< gfgtdf> vultraz: there is somwhere a fr to show the terrain the unit is standing on in the unti list.
20160809 11:10:13< gfgtdf> vultraz: did you or do you plan to implement that ?
20160809 11:10:31< vultraz> gfgtdf: first I'll port the dialog verbatim
20160809 11:10:40< vultraz> then I'll look to adding any other data
20160809 11:16:22< gfgtdf> vultraz: is there something you don't liek about smart_list ?
20160809 11:16:57< vultraz> well celticminstrel pointed out it sounds like deleted elements would start piling up
20160809 11:23:20-!- JyrkiVesterinen [~JyrkiVest@87-100-255-227.bb.dnainternet.fi] has quit [Quit: Going offline for ~an hour]
20160809 11:23:21< gfgtdf> vultraz: i thought smart_list used refcounting for each iterator position to make and frees then whe it it remved and the refcount is 0 ?
20160809 11:23:42< vultraz> i dunno, we haven't taken a closer look at it yet
20160809 11:24:40< vultraz> hoping to clean up const_cast calls, shared_object, and smart_list (maybe) tomorrow
20160809 11:24:55< vultraz> (shared_object seems unused, I think)
20160809 11:26:21< gfgtdf> vultraz: most const cast exists becasue some calsses missing const or non const version of some functions
20160809 11:27:24< gfgtdf> vultraz: problem is, for example for continer you want function 'const_iterator find(key) const;' and 'iterator find(key);' 
20160809 11:27:49< gfgtdf> vultraz: butg its annyoing to write each function twice, one in condt and once in non-const way,
20160809 11:27:58< gfgtdf> const*
20160809 11:28:35< gfgtdf> vultraz: so sometimes people just imtplement one by using the other + const cast.
20160809 11:29:53< gfgtdf> vultraz: some classes also uise a templat helepr function that can hande conts and non const and delegatto that, liek for example seen in https://github.com/wesnoth/wesnoth/blob/master/src/config.cpp#L71
20160809 11:30:23< gfgtdf> vultraz: this avoids the const cast but also makes te code a little more complicated
20160809 11:37:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160809 11:38:56-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160809 12:07:39-!- JyrkiVesterinen [~JyrkiVest@87-100-255-227.bb.dnainternet.fi] has joined #wesnoth-dev
20160809 12:44:45-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has quit [Ping timeout: 276 seconds]
20160809 12:46:27-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160809 12:56:09-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160809 12:58:26-!- travis-ci [~travis-ci@ec2-23-23-37-169.compute-1.amazonaws.com] has joined #wesnoth-dev
20160809 12:58:28< travis-ci> wesnoth/wesnoth#10260 (master - cf1d2e3 : Charles Dang): The build passed.
20160809 12:58:28< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/150854517
20160809 12:58:28-!- travis-ci [~travis-ci@ec2-23-23-37-169.compute-1.amazonaws.com] has left #wesnoth-dev []
20160809 13:10:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160809 13:10:38-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160809 13:11:08-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has joined #wesnoth-dev
20160809 13:11:16-!- JyrkiVesterinen [~JyrkiVest@87-100-255-227.bb.dnainternet.fi] has quit [Quit: JyrkiVesterinen]
20160809 13:13:58-!- JyrkiVesterinen [~JyrkiVest@87-100-255-227.bb.dnainternet.fi] has joined #wesnoth-dev
20160809 14:28:44-!- gfgtdf [~chatzilla@x4e36a72a.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160809 14:58:59-!- JyrkiVesterinen [~JyrkiVest@87-100-255-227.bb.dnainternet.fi] has quit [Quit: .]
20160809 15:00:06-!- Kwandulin [~Miranda@p200300760F35BF103885105974259480.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160809 15:33:55-!- Kwandulin [~Miranda@p200300760F35BF1065B62A0C2CCA72BB.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160809 15:49:28-!- boucman_work [~boucman@229.29.205.77.rev.sfr.net] has quit [Ping timeout: 265 seconds]
20160809 15:50:08-!- JyrkiVesterinen [~JyrkiVest@87-100-184-215.bb.dnainternet.fi] has joined #wesnoth-dev
20160809 15:51:49-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160809 15:53:15-!- Bonobo [~Bonobo@2001:44b8:254:3200:3801:7e55:9c62:35d1] has quit [Ping timeout: 264 seconds]
20160809 15:56:34< celticminstrel> 20160809 11:09:02< gfgtdf> vultraz: from the comments i'd guess trhat's so that we dont have to worry when we remove elements while iterating over that list
20160809 15:56:35< celticminstrel> If you iterate properly you don't need to worry about that anyway.
20160809 16:00:27-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160809 16:01:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160809 16:32:54-!- TC01 [~quassel@128.220.251.37] has quit [Ping timeout: 276 seconds]
20160809 16:33:45-!- irker481 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160809 16:33:45< irker481> wesnoth: Jyrki Vesterinen wesnoth:master 486293403e0f / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Update Visual Studio project https://github.com/wesnoth/wesnoth/commit/486293403e0fc59eea6b2aad8d1ebb3225341b94
20160809 16:43:20-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160809 16:44:10-!- TC02 is now known as TC01
20160809 16:46:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160809 16:54:59-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160809 16:55:19-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160809 16:57:28< celmin> I kind of want to port the Advance Unit dialog… but I don't want to fiddle with GUI2 WML… conundrums...
20160809 16:57:33-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160809 17:07:51-!- esr [~esr@wesnoth/developer/esr] has quit [Quit: WeeChat 1.3]
20160809 17:08:07-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160809 17:14:08< celmin> I had no idea that the unit list dialog was also used in the editor.
20160809 17:15:00< celmin> Ultimately I'd like to remove dialogs.cpp… once everything is ported to GUI2...
20160809 17:16:40< celmin> Actually I think Advance Unit is the last one in that file.
20160809 17:16:45< celmin> MP UI is somewhere else.
20160809 17:21:48-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160809 17:24:16< celmin> 'lo ancestral 
20160809 17:24:43-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160809 17:32:22-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160809 17:34:23< aeth> I'm not sure if there has been any progress on an OpenGL backend in the past few months but it looks like the facts have changed since I last talked about it in here.
20160809 17:34:57< celmin> I don't know of any progress towards that.
20160809 17:35:20< aeth> Mesa is slowly getting past 3.3 to 4.5 (currently mostly at 4.3) so it's getting to the point that it would probably make sense to have a 4.x OpenGL backend for Wesnoth (in addition to a 3.3 one for legacy computers afaik)
20160809 17:35:27< celmin> But if there is, Aginor probably knows.
20160809 17:35:32< celmin> BTW, I only have OpenGL 3.2
20160809 17:35:57< aeth> celmin: a really old iGPU or something?
20160809 17:36:11< celmin> I dunno what that means.
20160809 17:36:17< aeth> iGPU being the intel integrated afaik
20160809 17:36:30< celmin> Oh, no, it's not integrated graphics. It's nVidia.
20160809 17:36:35< aeth> ah
20160809 17:36:43< aeth> which one?
20160809 17:36:47< celmin> At least on the desktop. No idea about the laptop.
20160809 17:36:53< celmin> Uhh… what was it again...
20160809 17:37:21< celmin> GeForce 7300 GT
20160809 17:37:28< aeth> ah, that's quite old
20160809 17:37:43< celmin> The computer is ten years old now.
20160809 17:37:50< aeth> I had to recently replace my 9800 with a dirt cheap 750 Ti and mostly doubled performance.
20160809 17:38:07< celmin> I can't upgrade the graphics because there's no drivers.
20160809 17:38:45< aeth> If you're only doing the FOSS drivers, then AMD is viable now. You won't get what you pay for, but it will still considerably outperform the 7300 afaik.
20160809 17:38:51< celmin> Unless it was to the one or two other supported cards, but those are no longer avaiable AFAIK.
20160809 17:39:03< celmin> No, there are literally no drivers available.
20160809 17:39:20< celmin> As far as I know, there are no FOSS drivers either.
20160809 17:39:44< celmin> Plus most cards simply won't work in the computer.
20160809 17:40:12 * celmin as a reminder is a Mac user.
20160809 17:40:51< aeth> You're probably approaching the point where a mac mini will outperform what you have, if you're not already at that point.
20160809 17:41:06< aeth> 5-6 years seems to be what it takes to go from high end to low end afaik.
20160809 17:41:15< JyrkiVesterinen> celmin: Have you considered switching to GNU/Linux? That would give you a supported operating system (in particular security updates) and support for modern hardware.
20160809 17:41:16< vultraz> celmin: you can try, but be prepared to be frustrated
20160809 17:41:52< celmin> I have not considered switching to Linux.
20160809 17:41:59< aeth> Using the foss linux drivers will give you 3.3 for "free", perhaps in a dual boot
20160809 17:42:09< aeth> unless the hardware doesn't support it
20160809 17:42:13< celmin> I have a Fedora install on my new computer, but haven't really used it at all.
20160809 17:42:42< celmin> I actually don't use the computer much at all despite it being newer, because all my stuff is on the Mac and moving it is nontrivial.
20160809 17:42:49< aeth> btw, when my new GeForce 10 series card arrives, and I stop using my temporary 750 Ti, I will essentially have gone from GeForce 9 series to GeForce 10 series.
20160809 17:42:51< celmin> Some of my programs are Mac-only, for example.
20160809 17:43:09-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160809 17:43:15< celmin> 'lo ancestral 
20160809 17:44:11< aeth> celmin: I'm not sure it's reasonable to support OpenGL 3.2 over e.g. 3.3 given how rare 3.2 but not 3.3 is. If there is an OpenGL 'noth you'd probably have to stay on the legacy renderer.
20160809 17:44:23< aeth> Given how slowly Wesnoth moves it'd probably stick around for 4+ years.
20160809 17:44:57< celmin> …I thought it was 3.2 at least, maybe I misremembered...
20160809 17:45:16< aeth> celmin: https://support.apple.com/en-us/HT202823
20160809 17:45:28< aeth> All of the ones on that list are 3.3 or 4.1
20160809 17:45:43< aeth> For mesa I go off of this table: https://people.freedesktop.org/~imirkin/glxinfo/
20160809 17:45:53< aeth> which seems to suggest 3.3 or 4.3 (4.4-4.5 is coming)
20160809 17:46:02< celmin> Mine isn't even on that list.
20160809 17:46:17< ancestral> Okay, time to figure this SHA business
20160809 17:46:30< celmin> ancestral: Did you see my comment just after you left?
20160809 17:46:39< ancestral> No, but I can dig up the logs
20160809 17:48:32< celmin> According to this page I only have 3.2: https://developer.apple.com/opengl/capabilities/GLInfo_1075_Core.html
20160809 17:48:38< celmin> Though my card isn't listed.
20160809 17:48:53< aeth> celmin: have you tried looking for third party drivers? Maybe nvidia has/had them for OS X
20160809 17:49:22< celmin> General graphics cards do not work in the 2006 Mac Pro.
20160809 17:49:29< celmin> You need special Mac-compatible cards.
20160809 17:49:37< vultraz> wait, that's what you have?
20160809 17:49:43< vultraz> the 2006 macbook pro?
20160809 17:49:47< celmin> No.
20160809 17:50:10< aeth> Wikipedia says that your generation should only support OpenGL 2.1. https://en.wikipedia.org/wiki/GeForce_7_series
20160809 17:50:14< celmin> Where did you see me say "Macbook"?
20160809 17:50:26< aeth> So it's possible that Apple uses some software level or something
20160809 17:50:27< celmin> Hmm, maybe, I dunno.
20160809 17:50:51< ancestral> And LLVM?
20160809 17:50:53< aeth> celmin: Maybe try to find a Mac-compatible nvidia 8000s/9000s card that will just barely do 3.3?
20160809 17:51:03< celmin> If it only supports 2.1, that could explain why something wasn't working earlier...
20160809 17:51:19< aeth> If most hardware except iGPUs going back 10 years supports at least 3.3, you're probably going to have problems with 3D stuff in general.
20160809 17:51:34< aeth> and maybe you'll find a cheap barely 3.3 card
20160809 17:51:46< celmin> I can play Legend of Grimrock (though on reduced settings).
20160809 17:52:26< aeth> quite a lot of indie games still use legacy OpenGL 1.x because that's where all the tutorials were until extremely recently, even in the 4.x era... also immediate mode is way easier
20160809 17:52:35< aeth> but that's becoming increasingly uncommon now (past few years)
20160809 17:53:04< celmin> Immediate mode really is easier.
20160809 17:53:25< aeth> The most recent game on Steam I've seen with requirements of 1.x is Out of the Park Baseball '17 and that barely has any 3D in it since it's a sports management sim.
20160809 17:53:39< aeth> Not many new games are going that direction
20160809 17:55:35 * vultraz ponders using resources:: again
20160809 17:55:39-!- vincent_c [~bip@vcheng.org] has quit [Ping timeout: 264 seconds]
20160809 17:55:55< aeth> celmin: anyway, I think you're going to have increasing problems with 3D if the place people go for OS X support (the page I was on) only lists 3.3 and 4.1 for OpenGL
20160809 17:55:58< vultraz> I guess it's acceptable for now
20160809 17:56:30< celmin> I no longer use the Mac for gaming, so I'm not really worried. That's what the new Windows computer is for (mostly).
20160809 17:56:52< celmin> Well, that's not quite true. I do play some games on the Mac still, including but not limited to Wesnoth.
20160809 17:57:13< celmin> I'd be a little worried if Wesnoth was going to stop working on my Mac though.
20160809 17:57:35< aeth> I agree that the great thing about Wesnoth is just about any computer can run it
20160809 17:57:41< celmin> Anyway, requiring OpenGL 3.3 would mean dropping support for OSX 10.7.
20160809 17:57:51< celmin> Whereas requiring only 3.2 would not.
20160809 17:58:05< celmin> Though I guess it might not work on my computer specifically...
20160809 17:58:42< celmin> Does Wesnoth even need OpenGL3?
20160809 18:00:55< aeth> celmin: OpenGL 3 is fairly modern, but still quite outdated at this point, missing out on the OpenGL AZDO trend and the current Vulkan/DX12 hype. Of course both are quite overkill for a 2D game.
20160809 18:01:27< celmin> The last sentence seems the most relevant to me.
20160809 18:01:54< celmin> I'm sure Wesnoth can do just fine even with OpenGL 2.
20160809 18:01:55< aeth> 2D games have changed since Wesnoth came out, though. There are e.g. 2D lighting stuff. Lots of stuff can be done on the GPU for 2D games.
20160809 18:02:29< aeth> celmin: The problem is, does anyone want to write brand new code that might take 1-2 years to complete on such an outdated API that it doesn't provide a marketable skill and would be hard to get people to maintain?
20160809 18:03:22< aeth> OpenGL 2.1 is already more than 10 years old. By the time an OpenGL renderer is written, it will be several years older.
20160809 18:03:54< aeth> OpenGL 3.2 is sort of the bare minimum because it allows you to use the core profile and avoid the deprecated fixed-function
20160809 18:04:26< aeth> i.e. it would force programmers on a large project to use modernish OpenGL with shaders etc. instead of taking the legacy/slower but easier shortcuts
20160809 18:05:16< celmin> Shaders are annoying.
20160809 18:05:20-!- Kwandulin [~Miranda@p200300760F35BF1065B62A0C2CCA72BB.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160809 18:05:28< aeth> I'm not sure if there is a considerable advantage of 3.3 over 3.2
20160809 18:05:46< celmin> Well, OpenGL generally is kind of annoying too...
20160809 18:05:54< celmin> But shaders especially.
20160809 18:06:07< aeth> celmin: Shaders are annoying, but GPUs are basically a different way to compute.
20160809 18:07:08< aeth> GLSL is pretty bad because it's designed to be very similar to C, in a world that has mostly left C behind in the past 16 or so years... SPIR-V will fix that and is even coming to OpenGL as an extension soon, but that'll take a while.
20160809 18:07:43< celmin> Why do we need a separate language for programming the GPU anyway.
20160809 18:07:45< aeth> Gamedev stuff is mostly C++ and C# these days
20160809 18:07:51< celmin> Really?
20160809 18:08:11< celmin> Why is gamedev mostly C++? I mean, I like C++, but I get the impression that a lot of people don't.
20160809 18:08:14< aeth> celmin: well the point of GLSL is to not really give you a separate language because it's supposed to be very similar to C, while still taking into account that the GPU is different and some things won't work
20160809 18:08:52< aeth> but obviously if you're not using C for your engine (most engines these days) there will be differences. And not using C++ it'll seem even more different (at least Wesnoth uses C++)
20160809 18:09:21< celmin> I don't want to have to write shaders at all.
20160809 18:09:36< celmin> Can I have a library that writes them for me?
20160809 18:09:47< celmin> :P
20160809 18:09:53< aeth> Currently, for OpenGL you'd have to compile to GLSL strings like you can do with JavaScript.
20160809 18:10:05< JyrkiVesterinen> celmin: How about another programmer? You aren't alone in this project, you know.
20160809 18:10:09< aeth> Eventually, SPIR-V is going to be backported to OpenGL from Vulkan so you could compile to that.
20160809 18:10:18< celmin> JyrkiVesterinen: What are you talking about so suddenly?
20160809 18:10:42< JyrkiVesterinen> Just saying that if you don't want to write shaders, then other programmers may write them.
20160809 18:10:55< celmin> Ah, yeah. In the case of Wesnoth, sure.
20160809 18:11:05< celmin> But I have my own projects too.
20160809 18:11:52< aeth> celmin: oh gamedev is mostly C++ because big commercial middleware (like physics engines) is mostly C++... no reason for a smaller 2D or even 3D game to be C++ if you don't want it to be
20160809 18:12:04< celmin> Ah.
20160809 18:12:16< celmin> So it's the fault of Epic, iD, Valve, etc.
20160809 18:12:17< aeth> Also it's supposedly faster, but you can write slow code in any language.
20160809 18:12:23< celmin> Oh, Unity too.
20160809 18:12:29< aeth> And besides, the people who want really fast hand-tuned code *want* to use C but can't because of the C++ network effects.
20160809 18:12:35< aeth> So they write C in C++
20160809 18:12:46< celmin> C++ network effects?
20160809 18:13:21< aeth> celmin: gamedev has basically been captured by C++ ever since the big engines transitioned from C to C++ a long time ago (in the 90s?)
20160809 18:13:37-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160809 18:13:43 * celmin wonders if my list covers all the big engines.
20160809 18:13:46< aeth> I mean, even Wesnoth is in C++, that shows you how big the network effects are.
20160809 18:13:55< vultraz> Valve is not an engine
20160809 18:14:10< celmin> I know.
20160809 18:14:15< celmin> Source engine, right?
20160809 18:14:24< aeth> GoldSrc, Source, Source 2
20160809 18:14:26< celmin> iD is Quake engine, I think. Epic is Unreal engine.
20160809 18:14:28< aeth> Three engines now, all maintained.
20160809 18:14:40< celmin> Never heard of GoldSrc.
20160809 18:14:54< celmin> What about Unity?
20160809 18:14:58< aeth> GoldSrc is the Half Life 1 engine... also the original Counter-Strike, which a lot of people still play apparently
20160809 18:15:12< celmin> Oh, I see, so you're saying Valve has three engines.
20160809 18:15:21< JyrkiVesterinen> celmin: Unity uses primarily C# for scripting.
20160809 18:15:22< aeth> Unity is a custom C++/C# hybrid even though these days writing it in pure C# would probably be better since a lot of the C# issues (e.g. GC) have been greatly improved
20160809 18:15:32< aeth> Nowadays Unity is actually less performant than newer C# and uses a very old C# iirc
20160809 18:16:02< JyrkiVesterinen> Yes, that is correct. Unity uses an ancient version of Mono as the C# runtime and libraries.
20160809 18:16:39< aeth> You can definitely work around a GC in a game engine, and newer GCs are often decent. The ancient Unity version of C# gives GC a bad reputation in gamedev.
20160809 18:16:53< celmin> I think I'd rather not deal with a GC.
20160809 18:17:11< aeth> And if you were to write your own language, you can e.g. waste a lot of RAM to have a real time GC iirc
20160809 18:17:16< aeth> Since games have their own needs
20160809 18:17:27< JyrkiVesterinen> Unity also has an alternative pipeline called IL2CPP. It uses Mono to compile C# to CIL (Common Intermediate Language), compiles CIL to C++, and finally compiles C++ to machine code using whichever compiler the target platform supports.
20160809 18:17:40< JyrkiVesterinen> In particular, Unity uses IL2CPP on iOS and WebGL.
20160809 18:18:04< aeth> celmin: in practice, it's not that different GC or no GC. In a GC language, you're avoiding GC and in a non-GC language you're avoiding malloc
20160809 18:18:05< celmin> What qualifies as "machine code" for WebGL? JavaScript?
20160809 18:18:24< JyrkiVesterinen> Asm.js, which is a subset of JavaScript.
20160809 18:18:39< JyrkiVesterinen> I think Unity is also working on a WebAssembly target.
20160809 18:19:34< aeth> celmin: iirc (it's been a few months), what you want to do regardless of the language is allocate everything up front if possible
20160809 18:19:47< ancestral> I’m uploading again, this time via scp, as a new file name
20160809 18:19:59< celmin> aeth: Allocation pool?
20160809 18:20:56< aeth> http://gameprogrammingpatterns.com/contents.html
20160809 18:21:13< celmin> Oh my.
20160809 18:21:17< aeth> so http://gameprogrammingpatterns.com/object-pool.html
20160809 18:21:25< aeth> (I think)
20160809 18:21:27< celmin> But yeah, seems like I understood the idea.
20160809 18:21:37< loonycyborg> I think C++ is ever used because it allows people to get C level of performance and control while having access to higher level abstractions
20160809 18:21:58< celmin> Whoa, did you just use "ever" to mean "always"?
20160809 18:22:11< aeth> loonycyborg: you can get higher level abstractions in C, but it'll just be specific to your project or at least not quite standard
20160809 18:22:26< aeth> loonycyborg: the trend in engine development though is basically trying to ignore the higher level abstractions in C++, basically programming C in C++
20160809 18:22:33< loonycyborg> For development of more or less complex stuff you'll need powerful abstractions
20160809 18:22:47< aeth> e.g. "data driven" or something like that
20160809 18:22:55< loonycyborg> aeth: they for sure are using classes
20160809 18:23:09< aeth> loonycyborg: you don't have to use classes, either, you can do something like an ECS
20160809 18:23:13< celmin> ECS?
20160809 18:23:15< aeth> (without classes I mean)
20160809 18:23:31< loonycyborg> and for C only Linus can afford to reinvent all those wheels..
20160809 18:23:39< aeth> http://www.gamedev.net/page/resources/_/technical/game-programming/implementing-component-entity-systems-r3382
20160809 18:23:42< loonycyborg> everyone else are stuck with C++ :P
20160809 18:24:23< aeth> The problem with classes is the inheritance hierarchy can quickly become messy in game engines, so composition over inheritance is in style
20160809 18:24:36< JyrkiVesterinen> loonycyborg: At least the in-house engine of my former employer (written in C++) does use high-level abstractions.
20160809 18:24:58< JyrkiVesterinen> Although it's a mobile-focused engine, and thus doesn't need that much focus on performance.
20160809 18:25:20< JyrkiVesterinen> (Since mobile games aren't really competing fierely on graphics, unlike PC and console games)
20160809 18:25:24< aeth> JyrkiVesterinen: it depends on the era it's from... this trend to go closer to the metal (including on the GPUs with Vulkan/DX12) seems to be fairly recent
20160809 18:25:26< JyrkiVesterinen> *fiercely
20160809 18:25:31< aeth> and it also might be somewhat driven by mobile, too.
20160809 18:26:02< loonycyborg> I'm pretty sure that game devs are addicted on C++ classes
20160809 18:26:15< loonycyborg> and I'd expect them to adopt templates to, with various speeds
20160809 18:26:20< loonycyborg> *too
20160809 18:26:33< JyrkiVesterinen> I think the trend to go closer to the metal was driven simply by the increased performance gap between CPUs and GPUs.
20160809 18:26:56< JyrkiVesterinen> GPUs can be made faster by simply throwing more transistors into the chip. No such luck on the CPU side.
20160809 18:27:31< JyrkiVesterinen> The danger of games becoming CPU-bound has kept increasing.
20160809 18:27:46< aeth> I have read so many gamedev stuff that takes CPU cache into account.
20160809 18:27:46< JyrkiVesterinen> I think it's the ultimate reason for lower-level graphics APIs.
20160809 18:28:07< aeth> JyrkiVesterinen: depends on the genre, btw... building games, strategy, etc., has always been CPU bound afaik
20160809 18:28:20< aeth> you want lots of units/stuff
20160809 18:28:38< aeth> FPSes can get away with looking prettier but basically being the same sort of game as a 2003 FPS
20160809 18:28:55< aeth> For e.g. city builders people want much larger cities (Cities Skylines is a huge hog of CPU/RAM)
20160809 18:29:40< JyrkiVesterinen> (What's with everyone mentioning Finnish games here? First Legend of Grimrock, then Cities: Skylines.)
20160809 18:30:09< celmin> LoG is Finnish? Huh.
20160809 18:30:09< aeth> JyrkiVesterinen: The Nordic countries seem to do a good job producing games lower than AAA but higher than indie
20160809 18:30:24< aeth> I mean you can even count Minecraft in that
20160809 18:31:17-!- gfgtdf [~chatzilla@x4e36a72a.dyn.telefonica.de] has joined #wesnoth-dev
20160809 18:35:44< zookeeper> JyrkiVesterinen, i can assure you finnish games haven't usually been mentioned here very often :P
20160809 18:36:02< zookeeper> this was just a temporal glitch of some kind, i'm sure.
20160809 18:36:35< JyrkiVesterinen> Yeah, I believe you'd notice. ;)
20160809 18:37:25< loonycyborg> is it even a thing?
20160809 18:37:39< zookeeper> what is?
20160809 18:37:44< loonycyborg> all world is so globalized nowadays
20160809 18:37:55< loonycyborg> that there can't be a finnish game anymore :P
20160809 18:38:05< loonycyborg> only human-made game
20160809 18:38:32< zookeeper> we're a small enough country that we notice when anything made here gets any fame or mention in the outside world
20160809 18:38:32< aeth> loonycyborg: if you have to make the game engine to make the game, very few games count
20160809 18:38:44 * aeth slaps zookeeper around a bit with a large Nokia phone
20160809 18:38:50< celmin> Count for what?
20160809 18:38:59< aeth> celmin: loonycyborg's apparent standards
20160809 18:51:59-!- Kwandulin [~Miranda@p200300760F35BF10F9532CCECB2B20D7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160809 18:59:19< vultraz> blah, this status dialog is more complicated than I thought
20160809 18:59:30< celmin> Status dialog?
20160809 19:00:23< vultraz> the Game Status/Scenario Settings one
20160809 19:00:49< celmin> …Scenario settings? That sounds like an editor thing.
20160809 19:01:37< vultraz> nah
20160809 19:01:53< vultraz> it displays some settings for each side
20160809 19:03:37< gfgtdf> vultraz: what's the problem ?
20160809 19:04:38< vultraz> not a problem, just annoying accessing resources from all over the place.
20160809 19:04:39< gfgtdf> zookeeper: do you still intend to fix https://gna.org/bugs/?13154 ? It is assgned to you.
20160809 19:04:43< vultraz> I settled on just using resources::
20160809 19:05:07< vultraz> instead of passing parameters from menu_handler
20160809 19:05:22< celmin> Ugh.
20160809 19:06:37< vultraz> passing parameters around isn't any cleaner 
20160809 19:07:24< celmin> There's already 1488 uses of resources:: … it'd be great if we could actually reduce that...
20160809 19:07:48< celmin> How many parameters would you need to pass, anyway?
20160809 19:08:22< vultraz> I need resources::teams, resources::unit, and resources::gameboard
20160809 19:08:26< vultraz> units*
20160809 19:08:38< vultraz> for some reason, there's isn't a get_leader function in team
20160809 19:08:43< vultraz> (or is there?)
20160809 19:08:51< celmin> I feel like teams is accessible through gameboard...
20160809 19:09:00< celmin> Maybe not?
20160809 19:09:01< gfgtdf> vultraz: if there was it'd mostlikey using resourcess::
20160809 19:09:07< gfgtdf> use*
20160809 19:09:10< celmin> Might've been game_data or gamestate.
20160809 19:09:22< vultraz> nope, there isn't
20160809 19:09:33< vultraz> this is ridiculous 
20160809 19:09:36< gfgtdf> i alsol think you can get teemas and units form resources::gameboard
20160809 19:09:38< celmin> vultraz, I think the team class doesn't know anything about its units.
20160809 19:10:16< vultraz> gfgtdf: hm I think you're right
20160809 19:10:53< vultraz> maybe I'll just pass a gameboard parameter 
20160809 19:11:43< celmin> Huh? Why do I see two unit_recruit.cpp here. That's weird and impossible.
20160809 19:11:58< vultraz> eh?
20160809 19:12:00< vultraz> where
20160809 19:12:11< celmin> I think it must be a Finder glitch, because ls only shows one.
20160809 19:14:51< celmin> Trying to preview the glitched one with space gives me "No items selected".
20160809 19:15:27< celmin> Hold on, why do I still have an extra leader...
20160809 19:15:54< celmin> …oh right, because I'm still using [leader] tags in the test scenario.
20160809 19:16:22-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20160809 19:18:58< celmin> I just noticed that the recruit dialog's description is "Unut recruit dialog."
20160809 19:19:04< celmin> Where is the description used, anyway?
20160809 19:19:17< vultraz> No idea
20160809 19:19:26< celmin> Is it not supposed to be translatable?
20160809 19:19:40< vultraz> No idea
20160809 19:19:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160809 19:20:11-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160809 19:23:24-!- TC01_ [~quassel@london.acm.jhu.edu] has joined #wesnoth-dev
20160809 19:24:44< vultraz> how do I get a unit from find_leader()...
20160809 19:24:46< vultraz> hmm
20160809 19:24:58< vultraz> all the other cases use unit_map::iterator :|
20160809 19:25:31< celmin> vultraz: Good practice is to always make the associated include first.
20160809 19:25:46< celmin> ie, in xxx.cpp, xxx.hpp is the first include.
20160809 19:25:57< vultraz> uh.. yes?
20160809 19:25:58< vultraz> I do this
20160809 19:26:09< celmin> Well, someone didn't in unit_recruit.cpp.
20160809 19:26:09< vultraz> why
20160809 19:26:12< celmin> Anyway.
20160809 19:26:24< celmin> To get a unit from a unit_map::iterator, you just need operator*
20160809 19:26:25< vultraz> oh
20160809 19:26:26< vultraz> huh
20160809 19:26:32< vultraz> operator*?
20160809 19:26:40< celmin> ie, if iter is a unit_map::iterator, then *iter is a unit&
20160809 19:26:54< celmin> And if iter is a unit_map::const_iterator, then *iter is a const unit&
20160809 19:27:35< celmin> I suppose it might be * instead of &, but if that's so you just need **iter instead of *iter...
20160809 19:28:10< vultraz> I guess I need to use unit directly and not unit_const_ptr
20160809 19:28:29-!- gfgtdf [~chatzilla@x4e36a72a.dyn.telefonica.de] has quit [Remote host closed the connection]
20160809 19:29:28< celmin> Is there any point in including GUI2_EXPERIMENTAL_LISTBOX support in new dialogs?
20160809 19:29:33< celmin> I don't see the point myself.
20160809 19:29:47< vultraz> I just copypaste stuff
20160809 19:29:49< vultraz> and it comes along
20160809 19:30:00< celmin> Eh, whatever.
20160809 19:30:06< vultraz> honestly at this point the "experimental" listbox is so far behind the "old" listbox/
20160809 19:30:10 * celmin just copied unit_recruit and renamed it unit_advance anyway.
20160809 19:30:22< vultraz> oh ho ho
20160809 19:30:29< vultraz> making gui2 dialogs now, are we? :D
20160809 19:30:39< celmin> Meh.
20160809 19:32:58< vultraz> &* is rather ugly
20160809 19:33:06< celmin> Why do you need it?
20160809 19:33:19< celmin> There may be a less ugly way.
20160809 19:33:31< vultraz> I should probably get a pointer so I can check easily in if()
20160809 19:33:42< celmin> Is there a help topic suitable for linking from the advance unit dialog?
20160809 19:33:47-!- irker481 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160809 19:33:52< celmin> Check what easily?
20160809 19:33:57< vultraz> if it's valid
20160809 19:33:58< celmin> I can't help you when I have no idea what you're doing.
20160809 19:34:15< vultraz> the gui1 dialog did this:
20160809 19:34:21< vultraz> 		unit_map::const_iterator leader = units().find_leader(n + 1);
20160809 19:34:23< vultraz> 		if(leader != units().end()) {
20160809 19:34:35< vultraz> I'm doing this
20160809 19:34:44< vultraz> 		const unit* leader = &*board_.units().find_leader(team.side());
20160809 19:34:46< vultraz> 		if(!leader) {
20160809 19:35:29< celmin> So find_leader returns unit_map::const_iterator.
20160809 19:35:36< celmin> Why not call .get_shared_ptr()?
20160809 19:35:51< vultraz> ah, that thing
20160809 19:35:53< celmin> That gives you a const_unit_ptr (which is basically equivalent to a const unit*)
20160809 19:35:58< vultraz> (we should rename that)
20160809 19:36:07< vultraz> (it doesn't give you a shared_ptr)
20160809 19:36:18< celmin> If you want to rename it to get_ptr(), that's fine with me, but don't call it get_intrusive_ptr.
20160809 19:36:41< vultraz> :P
20160809 19:36:54< celmin> There might already be a get_ptr.
20160809 19:36:57< celmin> I dunno.
20160809 19:37:22-!- oldlaptop [~quassel@50.36.241.195] has quit [Ping timeout: 250 seconds]
20160809 19:37:51< vultraz> there is not
20160809 19:38:35-!- oldlaptop [~quassel@50.36.241.195] has joined #wesnoth-dev
20160809 19:46:07< celmin> Why do we have LOW_MEM anyway?
20160809 19:46:19< celmin> Was it a concern for some people?
20160809 19:47:08< vultraz> I guess TCing images was considered high-mem at some point
20160809 19:47:18< celmin> Well, it is though.
20160809 19:47:18< vultraz> Certain people said it should stick around as reference
20160809 19:47:23< vultraz> However I am purging it
20160809 19:47:41< celmin> Isn't TCing basically "copy this image, then run through each pixel and update it"?
20160809 19:47:52< celmin> That's an O(w*h) operation.
20160809 19:47:55< vultraz> not sure
20160809 19:49:41< vultraz> it could probably be optimized
20160809 19:50:31< celmin> I doubt it.
20160809 19:51:18< celmin> I think the most you could do is update the pixels as part of the copy, but that only reduces runtime by half, so it's still O(w*h).
20160809 19:51:30< celmin> (Half at best, not quite sure if it would be that in practice.)
20160809 19:51:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160809 19:52:04-!- gfgtdf [~chatzilla@x4e36a72a.dyn.telefonica.de] has joined #wesnoth-dev
20160809 19:58:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160809 20:02:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160809 20:03:24< celmin> Oh, I should show overlays here too...
20160809 20:04:11< celmin> Or should I? I dunno.
20160809 20:04:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160809 20:04:57< celmin> vultraz: What do you think?
20160809 20:06:46< vultraz> where?
20160809 20:07:46< celmin> Advance unit dialog.
20160809 20:07:47-!- RatArmy [~RatArmy@om126212249091.14.openmobile.ne.jp] has joined #wesnoth-dev
20160809 20:08:21< vultraz> in the list?
20160809 20:08:22< vultraz> nah
20160809 20:08:31< celmin> No, in the preview.
20160809 20:08:46< celmin> Oh, wait, maybe the preview pane already does that.
20160809 20:09:00< celmin> Now that you mention it, yeah, definitely not in the list.
20160809 20:10:43< vultraz> the great thing about the preview is you don't have to do anything to do it :)
20160809 20:11:16-!- RatArmy [~RatArmy@om126212249091.14.openmobile.ne.jp] has quit [Client Quit]
20160809 20:11:21< vultraz> s/do//
20160809 20:11:39-!- RatArmy [~RatArmy@om126212249091.14.openmobile.ne.jp] has joined #wesnoth-dev
20160809 20:14:19< celmin> So, "you don't have to anything to it"? :P
20160809 20:15:34< vultraz> blah
20160809 20:15:38< vultraz> the second do
20160809 20:15:43< celmin> :P
20160809 20:15:56< vultraz> dunno how to say the second one
20160809 20:15:59-!- trewe [~trewe@2001:8a0:d118:6301:52e2:38cb:dbe6:c25] has joined #wesnoth-dev
20160809 20:16:00< vultraz> s/do/2//?
20160809 20:16:30-!- RatArmy [~RatArmy@om126212249091.14.openmobile.ne.jp] has quit [Ping timeout: 244 seconds]
20160809 20:16:54< celmin> I don't know if there is a way.
20160809 20:18:49-!- Kwandulin [~Miranda@p200300760F35BF10F9532CCECB2B20D7.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160809 20:26:48< vultraz> why the hell does get_side_highlight_pango increase its argument by 1...
20160809 20:27:32< celmin> Teams are 0-indexed in some places and 1-indexed in others.
20160809 20:27:50< celmin> It's kind of a huge mess really.
20160809 20:27:52< vultraz> are yo ()*$)(@*#) kidding me :|
20160809 20:28:11< celmin> I'm pretty sure this is the case.
20160809 20:28:16 * vultraz weeps
20160809 20:28:18< celmin> I could be misinterpreting something though.
20160809 20:28:36< celmin> But it's certainly try that there's tons of places that adjust team numbers by 1 to adjust for this.
20160809 20:28:41< celmin> And not just in Lua.
20160809 20:28:51< celmin> ^true
20160809 20:30:02-!- RatArmy [~RatArmy@om126212249091.14.openmobile.ne.jp] has joined #wesnoth-dev
20160809 20:30:41< gfgtdf> map_locations are also havea  similar issue, i wonder whther we shoudl change our intenral maplocations to match the wml format, so that we dont have to add/subtract 1 when parsing wml moa locations.
20160809 20:31:01< celmin> Yeah, map_location does also have this issue.
20160809 20:31:19< celmin> I think we should change map_locations to match the WML/Lua standards.
20160809 20:31:32< celmin> I think the situation with teams is more complicated though.
20160809 20:31:45< celmin> I guess a good start would be not allowing direct access to the teams array.
20160809 20:33:24< vultraz> nooo
20160809 20:34:54< celmin> What?
20160809 20:35:32< vultraz> don't do that
20160809 20:35:38< vultraz> how would one access all teams, then?
20160809 20:35:53< celmin> Hmm, you have a point, but I think it could be arranged nonetheless.
20160809 20:36:53< vultraz> the very dialog I'm working on right now requires me to be able to access the teams array
20160809 20:37:03< celmin> I doubt that.
20160809 20:37:18< celmin> Rather, I doubt that it requires you to be able to access the teams array directly.
20160809 20:37:56< celmin> Assuming I did this, looking up a specific team would be something like .get_team(num) instead of .teams()[num].
20160809 20:38:29< celmin> And iterating through teams might be for(int i = 1; i <= .num_teams(); i++), not sure.
20160809 20:39:02< vultraz> accessing directly allows range-for loops
20160809 20:39:13< celmin> Could also make .teams() return an iterator range, then range-for is still supported.
20160809 20:39:31< celmin> But I don't think it's terrible to not support range-for, you know.
20160809 20:40:05< vultraz> *gasps*
20160809 20:40:36-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160809 20:40:57< gfgtdf> i think replacein all resources::teams access with gameboard::teams() is a good start.
20160809 20:41:19< vultraz> agreed
20160809 20:42:46< celmin> A regular index-based for-loop isn't all that ugly.
20160809 20:43:31< vultraz> true
20160809 20:43:35< vultraz> I just really like range-for :P
20160809 20:43:46< JyrkiVesterinen> Range-based loop hides indices, which is very useful in this case (trying to harmonize team indices).
20160809 20:43:57< celmin> Could be, yeah.
20160809 20:47:28-!- JyrkiVesterinen [~JyrkiVest@87-100-184-215.bb.dnainternet.fi] has quit [Quit: Going to bed]
20160809 20:49:24< celmin> If I recall correctly, there's a function in team that returns its 1-based side number, right?
20160809 20:50:53< gfgtdf> celmin: there should be.
20160809 20:51:16< celmin> That's so ambiguous.
20160809 20:51:39< celmin> It could mean "I think there's one but am not quite sure", or "There isn't one but it should be added".
20160809 20:52:37< gfgtdf> celmin: the first
20160809 20:54:56-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160809 21:01:10< vultraz> celmin: these two should be equivalent, right? http://pastebin.com/Q8FEsFW0
20160809 21:01:15< vultraz> haven't had my coffee yet
20160809 21:01:18< vultraz> still sluggish
20160809 21:03:11< celmin> Okay, so combining those two conditions naïvely would yield if(game_config::debug || !(enemy && viewing_team.uses_fog()))
20160809 21:03:34< celmin> Applying DeMorgan's law produces if(game_config::debug || !enemy || !viewing_team.uses_fog())
20160809 21:03:57< celmin> Wait, I think that's not the right law.
20160809 21:04:00-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160809 21:04:16< vultraz> former looks cleaner
20160809 21:04:18< celmin> Oh, no, it is.
20160809 21:04:27< celmin> How does the former look cleaner?
20160809 21:04:30< vultraz> er
20160809 21:04:32< vultraz> wait no
20160809 21:04:35< vultraz> latter looks cleaner
20160809 21:04:44< celmin> Because no parentheses, right?
20160809 21:04:51< vultraz> CLEARER*
20160809 21:04:54< vultraz> jeez
20160809 21:05:01< celmin> Oh, well, whatever.
20160809 21:05:04< vultraz> it's easier to tell what the condition says
20160809 21:05:40< vultraz> !(a && b) means... false if a and b are both true
20160809 21:06:47< vultraz> er, wait
20160809 21:06:54< vultraz> don't we need that?
20160809 21:07:03< vultraz> using OR in all three cases breaks the second conditional
20160809 21:07:08< celmin> How so?
20160809 21:07:28-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 258 seconds]
20160809 21:07:28-!- wedge010 is now known as wedge009
20160809 21:07:29< celmin> if(a) {stuff} else if(b) {stuff} is equivalent to if(a || b) {stuff}, right?
20160809 21:07:34< celmin> Assuming all three stuff are the same, of course.
20160809 21:08:03< vultraz> yes, but in this case b is (b && c)
20160809 21:08:29< celmin> And if(a) {stuff} else if(b) {other_stuff} else {stuff} is equivalent to if(a || !b) {stuff} else {other_stuff}
20160809 21:08:29< vultraz> so unless I'm mistaken
20160809 21:08:32< vultraz> ....
20160809 21:08:41< vultraz> yes
20160809 21:08:48< celmin> And in this case b is actually (x && y)
20160809 21:08:59< vultraz> yes
20160809 21:09:03< vultraz> which is why I'm saying
20160809 21:09:10< vultraz> is not
20160809 21:09:11< vultraz> if(game_config::debug || !enemy || !viewing_team.uses_fog())
20160809 21:09:13< vultraz> wrong?
20160809 21:09:15< celmin> So you have a || !(x && y) <=> a || (!x || !y) <=> 1 || !x || !y
20160809 21:09:49< celmin> <=> is "logical equivalence", or in other word boolean equality.
20160809 21:09:56< celmin> ^words
20160809 21:10:13< vultraz> s/1/a?
20160809 21:10:24< celmin> Well, no, it's not quite the same as boolean equality, it's more "these two expressions are equivalent for any possible set of inputs".
20160809 21:10:30< celmin> Yes, 1 should've been a.
20160809 21:10:46< vultraz> I see
20160809 21:11:03< celmin> I've now explained my whole line of reasoning.
20160809 21:11:06< vultraz> dunno why this should confuse me
20160809 21:11:13< vultraz> it's very simple >_>
20160809 21:13:01< vultraz> oh, I see
20160809 21:13:03< vultraz> I think
20160809 21:13:09< vultraz> x && y means both have to be true.
20160809 21:13:14< celmin> Yes.
20160809 21:13:24< celmin> !(x && y) means both have to be false.
20160809 21:13:45< celmin> Wait no.
20160809 21:13:53< vultraz> so if you do !x || !y and one of those is true, the whole expression would not have passed anyway
20160809 21:13:58< vultraz> wait no
20160809 21:14:08< celmin> !(x && y) does not mean that both need to be false.
20160809 21:14:15< vultraz> ! reverses the result, right?
20160809 21:14:40< celmin> !(x && y) means that (x && y) is false, which means that it is not the case that both x and y are true.
20160809 21:14:40< vultraz> pretty sure !a is different from a == false.
20160809 21:14:46< celmin> So, at least one of them is false.
20160809 21:15:07< celmin> !a is obviously diffferent from comparing with false.
20160809 21:15:24< celmin> "at least one is true" is ||
20160809 21:15:29< vultraz> yet they're practically the same, I think.
20160809 21:15:35< celmin> ie, (x || y) means at least one is true.
20160809 21:15:41< vultraz> right
20160809 21:15:42< celmin> Thus (!x || !y) means at least one is false.
20160809 21:15:47< vultraz> right
20160809 21:15:52< celmin> Which is the same as !(x && y)
20160809 21:17:40< vultraz> if one of them were false that would be
20160809 21:17:47< vultraz> !(false && true)
20160809 21:17:50< vultraz> !(false)
20160809 21:17:52< vultraz> true
20160809 21:17:54< vultraz> I think
20160809 21:17:55< vultraz> ?
20160809 21:18:09< celmin> Yes.
20160809 21:19:26< vultraz> so that expression runs true if x or y is false. and !x || !y also runs true if x or y is false.
20160809 21:19:46< vultraz> er
20160809 21:20:36< vultraz> I guess if !x or !y returns false, technically
20160809 21:20:44< vultraz> since ! reverses the result
20160809 21:20:49< vultraz> (I think)
20160809 21:21:36< vultraz> !true means false.
20160809 21:21:40< vultraz> yeah I think I get it now
20160809 21:21:41< celticminstrel> Yes.
20160809 21:21:56< celticminstrel> But it's if !x oe !y returns true.
20160809 21:22:01< celticminstrel> Since ! reverse the result.
20160809 21:22:05< celticminstrel> ^or
20160809 21:22:06< vultraz> right
20160809 21:22:15< vultraz> that's why I said [08:20:34]	vultraz	I guess if !x or !y returns false, technically
20160809 21:22:22< vultraz> er
20160809 21:22:33< vultraz> no
20160809 21:22:34< vultraz> wit
20160809 21:22:50< celmin> Right, that's what I was correcting.
20160809 21:23:06< celmin> If one of x or y is false, then that means that one of !x or !y is true.
20160809 21:23:07< vultraz> are you saying
20160809 21:23:09< vultraz> !x is true
20160809 21:23:12< vultraz> or x is true
20160809 21:23:19< vultraz> yes, I know that
20160809 21:23:29< vultraz> I'm just not sure which one you're talking about
20160809 21:23:35< celmin> Which what?
20160809 21:24:01< vultraz> if x is true !x evaluates as false. If !x is true than x was false.
20160809 21:24:07< vultraz> then*
20160809 21:24:25< celmin> Yes.
20160809 21:24:36< celmin> This is all basic logic. :P
20160809 21:24:44< vultraz> Which I know
20160809 21:24:49< vultraz> So why are we running in circles here
20160809 21:25:05< celmin> I'm not sure anymore.
20160809 21:25:10< vultraz> I feel we're walking over each other at this point
20160809 21:25:14< vultraz> And confusing each other
20160809 21:25:16< celmin> Maybe.
20160809 21:25:48< celmin> Though I still think that the line you quoted is wrong or, at best, highly misleading.
20160809 21:26:28< vultraz> What i was trying to say was this
20160809 21:27:16< vultraz> oh wait
20160809 21:27:20< vultraz> I see what you mean
20160809 21:27:35< vultraz> with || either has to return true NOT false
20160809 21:27:40< vultraz> or the condition doesn't pass
20160809 21:28:16< vultraz> yeah, I was looking at it the wrong way
20160809 21:28:24< vultraz> in the context of !(X && y)
20160809 21:28:39< celmin> What should I put for definition key of [label]?
20160809 21:28:51< celmin> For "What should our victorious unit become?"
20160809 21:29:32< vultraz> since in !x || !y either x or y needs to return false to be flipped to true to pass the condition
20160809 21:29:44< vultraz> celmin: well, if it's the title, "title". else "default"
20160809 21:30:47-!- gfgtdf [~chatzilla@x4e36a72a.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0/20160726073904]]
20160809 21:31:04< celmin> leader_lock seems to be missing from the list of keys in… I think it was teambuilder.cpp?
20160809 21:32:19-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160809 21:32:44< celmin> BTW, ancestral 
20160809 21:33:14< celmin> Were you planning to upload new "Mac Compile Stuff" at some point? 
20160809 21:33:18< ancestral> Yes
20160809 21:33:27< celmin> I have "wesnoth" and 
20160809 21:33:35< celmin> "wesnothd" shellscripts in my repo root dir.
20160809 21:33:47< celmin> I think something similar might be a useful inclusion in that.
20160809 21:34:31< ancestral> shell scripts
20160809 21:34:32< ancestral> ?
20160809 21:34:58< celmin> Yes, all they do is forward arguments to the wesnoth executable in XCode's DerivedData directory.
20160809 21:35:30< celmin> Very simple to write, mind you - could put it on the wiki instead.
20160809 21:35:42< ancestral> Whatever you think, I trust you
20160809 21:36:25< celmin> This is what the "wesnoth" script looks like: http://pastebin.com/qbXnFVdW
20160809 21:36:33< celmin> The "wesnothd" is just one letter different.
20160809 21:37:24< celmin> If they're in the package you'd want some explanation somewhere telling you to put them in the repo root dir.
20160809 21:42:09-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20160809 21:42:12< ancestral> BTW removing the xattrs does not change the checksum locally
20160809 21:42:32< celmin> Huh, okay, so why else could the checksum be changing...
20160809 21:42:39< ancestral> I am uploading the file to my personal server and going to check the sha256 there
20160809 21:42:48< ancestral> I am preparing a ticket with SF
20160809 21:44:15-!- Appleman1234 [~Appleman1@KD036012020120.au-net.ne.jp] has quit [Ping timeout: 276 seconds]
20160809 21:52:00< vultraz> it's SF, what do you expect if it screws up
20160809 21:54:59< Aginor> them not to modify/corrupt the files
20160809 21:55:02< Aginor> and to fix it
20160809 21:56:00< Aginor> I'm willing to attibute it to a fault instead of malice, but they have had problems in the past with inserting adware/spyware into downloads
20160809 21:56:06< celmin> Supposedly SF got new management recently and is cleaning up.
20160809 21:56:09< Aginor> they claimed to have stopped though
20160809 21:56:15< celmin> Yeah, that.
20160809 22:01:59< vultraz> celmin: !(x || y) == !x && !y, right?
20160809 22:03:56< celmin> Those are equivalent by DeMorgan's laws, yes.
20160809 22:10:56< zookeeper> holy crap that spectre hp bar problem is bad.
20160809 22:11:10< zookeeper> ( https://forums.wesnoth.org/viewtopic.php?p=599967#p599967 )
20160809 22:11:11-!- Appleman1234 [~Appleman1@KD036012028174.au-net.ne.jp] has joined #wesnoth-dev
20160809 22:11:43< celmin> Yeah.
20160809 22:13:35< vultraz> do you guys realize how long it's been since that change was introduced?
20160809 22:13:40< vultraz> how is it only an issue now
20160809 22:14:50< zookeeper> it's not in 1.12
20160809 22:15:16< zookeeper> so not long at all
20160809 22:15:22< celmin> What change?
20160809 22:15:40< zookeeper> there was some hp bar positioning thing done semi-recently, it must be due to that
20160809 22:15:41< vultraz> anchoring the bars to the top left
20160809 22:16:02< vultraz> I remember the commit that introduced it
20160809 22:16:11< celmin> Is it easily revertible?
20160809 22:16:17< celmin> Because it really looks bad.
20160809 22:16:18< vultraz> perhaps
20160809 22:16:44< zookeeper> obviously one should first check if just trimming the pointless padding from the sprite is enough.
20160809 22:16:52< vultraz> what did zookeeper mean by redesigning the bar display?
20160809 22:17:04< zookeeper> what?
20160809 22:17:54< vultraz> https://forums.wesnoth.org/viewtopic.php?p=574432#p574432
20160809 22:18:21< zookeeper> well i meant exactly that. no details.
20160809 22:18:28< zookeeper> i have no particular ideas
20160809 22:18:37< vultraz> sadness
20160809 22:18:46< vultraz> horizontal bars wouldn't work either
20160809 22:19:11< celmin> Okay, given a unit, how do I find the most-recently-applied modification...
20160809 22:19:14< zookeeper> maybe ask someone unnamed who wanted these kinds of gargantuan sprites in the first place
20160809 22:20:03< vultraz> gargantuan sprites are good
20160809 22:20:08< celmin> In WML it's easy...
20160809 22:21:01< celmin> Ah.
20160809 22:21:04< celmin> I see.
20160809 22:21:28< zookeeper> either they're good and there's no problem and we're all just hallucinating, or there is a problem and thus they're not that good after all.
20160809 22:21:47< vultraz> the sprites are not the problem
20160809 22:22:05< zookeeper> the sprites are the problem
20160809 22:22:31< vultraz> well unless you propose removing our lovely Fire Dragon, let's come up with a solution :)
20160809 22:22:42< zookeeper> of course that's what i've always proposed
20160809 22:22:44< zookeeper> it's crap
20160809 22:22:53 * vultraz spits coffee
20160809 22:22:55< vultraz> WHAT?
20160809 22:23:08< celmin> I suppose it is a little ugly.
20160809 22:23:15< vultraz> and I'm sure you have a better-looking sprite?
20160809 22:23:39< zookeeper> yeah the animated one (pixelmind's?) was great, and of more reasonable size
20160809 22:23:40< vultraz> what about the Skeletal Dragon
20160809 22:24:21< zookeeper> well it's obviously the same as the fire dragon
20160809 22:24:25< celmin> I don't remember what the old fire dragon looked like anymore.
20160809 22:24:37< celmin> Not sure if I ever did actually.
20160809 22:24:38< vultraz> it isn't the same as the fire dragon
20160809 22:24:44< vultraz> for one, it's totally different :|
20160809 22:24:56< vultraz> #LogicQuoteOfTheDay ;D
20160809 22:25:23< zookeeper> fine, it has a slightly different neck and wings, but the size remains the same
20160809 22:26:40< vultraz> Next you'll say you don't like the Spectre either
20160809 22:27:09< zookeeper> of course i don't. where do you get these ideas that i like everything you and jetrel like?
20160809 22:28:05-!- RatArmy [~RatArmy@om126212249091.14.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20160809 22:28:15< celmin> Heh.
20160809 22:28:20< zookeeper> the spectre is ridiculously oversized, so i don't like it. otherwise it's naturally cool.
20160809 22:28:21< vultraz> so if it were up to you
20160809 22:28:26< vultraz> everything would be 72x72
20160809 22:28:31< vultraz> precisely 
20160809 22:28:41-!- RatArmy [~RatArmy@om126212249091.14.openmobile.ne.jp] has joined #wesnoth-dev
20160809 22:29:02< zookeeper> not quite, but certainly closer to 72x72 than, say, 160x200
20160809 22:29:12< celmin> I honestly don't see why there's any need to allow larger sprites, but whatever. The ones we do have are mostly nice.
20160809 22:30:43< zookeeper> i have no problem with stuff poking outside hex boundaries and stuff, i only object to these later iterations of creeping biggerism and disregard for the environments the units will actually be in.
20160809 22:31:34< vultraz> The dragon is SUPPOSED to be big
20160809 22:31:49< celmin> The dragon is actually kinda problematic if I recall correctly.
20160809 22:34:06< zookeeper> anything becomes problematic when it extends not only to the surrounding hexes, but beyond them
20160809 22:34:59-!- RatArmy [~RatArmy@om126212249091.14.openmobile.ne.jp] has quit [Ping timeout: 244 seconds]
20160809 22:35:15< vultraz> Ok, half the Status dialog is working
20160809 22:35:21< celmin> Yay?
20160809 22:35:37< celmin> My dialog has only just reached the point of being able to test it.
20160809 22:37:04-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160809 22:38:53< zookeeper> anyway, the spectre problem seems easily fixable indeed
20160809 22:43:37< zookeeper> i'll do that right away
20160809 22:46:38-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160809 22:46:41-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160809 22:47:27-!- irker747 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160809 22:47:27< irker747> wesnoth: ln-zookeeper wesnoth:master 642323ff4562 / changelog data/core/images/units/undead/spectre.png: Cropped the Spectre baseframe to fix hitpoint bar positioning bug https://github.com/wesnoth/wesnoth/commit/642323ff4562154f95fe70052c10aac063f1fad3
20160809 22:48:00< vultraz> You sure we support different sizes for animation frames?
20160809 22:48:39< celmin> I assume zookeeper actually tested it.
20160809 22:49:07< zookeeper> the baseframe is not used in the standing animation
20160809 22:49:13< zookeeper> but even if it was, yes, it'd be supported
20160809 22:57:57< celmin> Do any addons use = in AMLA descriptions?
20160809 22:58:23< celmin> (Like the message option syntax, eg col1=col2)
20160809 22:58:33< zookeeper> i can check if you give me a regex
20160809 22:58:38< celmin> Hmm.
20160809 23:01:27< zookeeper> i can check for description\=.*\= and you can weed out false positives based on context
20160809 23:01:36< celmin> I was going to suggest this:
20160809 23:02:05< celmin> grep -Er 'description=.*=' addons/*/units/
20160809 23:02:25< celmin> So the same pattern you came up with, basically, plus telling grep to only look in units folders.
20160809 23:03:00 * celmin isn't quite sure of the directory structure on the server, so it might be a bit different.
20160809 23:03:16< celmin> The r in -Er tells grep to search all files in the specified folders.
20160809 23:03:29< celmin> The E may be default, but I've gotten used to putting it there just in case.
20160809 23:04:18< zookeeper> well amlas might not be in units/...
20160809 23:05:20< celmin> True.
20160809 23:05:45< celmin> Silly me for not thinking of that.
20160809 23:06:20< celmin> Hmm.
20160809 23:06:31< celmin> I feel like weeding out false positives could be really hard.
20160809 23:06:56< zookeeper> http://pastebin.com/jfMC3m8c <- sorry, it's really verbose :p i didn't think there would be that many either
20160809 23:07:29< celmin> Well, I'll take a look through those, anyway...
20160809 23:07:44< zookeeper> eh, wait a sec...
20160809 23:07:48< zookeeper> where are the ='s
20160809 23:07:54< celmin> Hmm?
20160809 23:08:06< zookeeper> oh right, nevermind
20160809 23:08:25< zookeeper> i mentally filtered out all those "<span color="'s and thought i had messed up the search
20160809 23:08:46< celmin> Yeah, some of them are from Pango markup rather than the description syntax.
20160809 23:09:09< zookeeper> anyway, that's the best i can do right now since i'm heading to bed
20160809 23:09:17< celmin> Maybe I can filter it further.
20160809 23:09:55< celmin> Looking at some of these, I'm wondering if the + for string concatenation is even needed in WML.
20160809 23:10:15< celmin> They seem to act as though string concatenation is implicit everywhere.
20160809 23:10:32< celmin> But, maybe they're just wrong.
20160809 23:17:15< zookeeper> i expect it's necessary at the very least when stuff is split onto multiple lines
20160809 23:18:00< celmin> Oh, right, true/
20160809 23:18:44< celmin> I kinda feel like Wesnoth should implement some sort of text markup syntax. Pango's markup syntax is really terrible.
20160809 23:19:59< celmin> It could also be used in help. The help markup syntax is kinda bad too.
20160809 23:20:48< celmin> Hmm, if I strip out all cases of <span and all cases of <img, I'm left with nothing in 1.13.
20160809 23:23:27-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds]
20160809 23:25:25< vultraz> gui2's [text] doesn't like markup
20160809 23:25:26< vultraz> blah
20160809 23:25:39< celmin> Huh?
20160809 23:26:05< vultraz> or...
20160809 23:26:07< vultraz> wait
20160809 23:26:09< vultraz> hm
20160809 23:26:24< celmin> Okay, so none of those instances zookeeper found look like they're from [advancements].
20160809 23:26:37< celmin> So I'll edit the wiki to remove that reference.
20160809 23:28:53< celmin> vultraz: Do you know if there's anything in mainline where a unit has both regular advancement options and AMLA options?
20160809 23:29:09 * celmin can easily make one if necessary, of course.
20160809 23:29:10< vultraz> i do not
20160809 23:29:19< celmin> Okay, I'll do that then.
20160809 23:30:30< vultraz> I cannot get these header labels to respect \n... :|
20160809 23:32:06< celmin> \n is not markup
20160809 23:32:15< celmin> What is [text], is that a canvas thing?
20160809 23:33:01< vultraz> yes
20160809 23:33:22< celmin> Then you should probably have one [text] for each line.
20160809 23:33:44< vultraz> what?
20160809 23:33:46< vultraz> no
20160809 23:34:00< celmin> Why not?
20160809 23:34:42< vultraz> [text] is how labels draw their text
20160809 23:34:51< vultraz> it's something in the implementation... 
20160809 23:35:08< celmin> Labels do support markup.
20160809 23:35:13< vultraz> yes
20160809 23:35:22< celmin> I thought you just said [text] doesn't.
20160809 23:35:36< vultraz> I was wrong
20160809 23:35:53< vultraz> labels set the use_markup flag
20160809 23:36:13< vultraz> when calling ttext..
20160809 23:36:20< vultraz> or..
20160809 23:36:21< celmin> So the \n problem is separate?
20160809 23:36:43< vultraz> no, seems [text] by itself doesn't take markup
20160809 23:37:37< celmin> I don't get what
20160809 23:37:41< celmin> 's going on here at all
20160809 23:39:31< vultraz> hmmm
20160809 23:39:43< vultraz> ok, think I got it to use markup..
20160809 23:39:50< vultraz> but it still doesn't seem to accept \n
20160809 23:39:52< vultraz> blag
20160809 23:40:59< vultraz> I dunno why tlabel calls font::ttext directly
20160809 23:41:16< vultraz> I'm not sure what 'mutable' does
20160809 23:42:51< celmin> mutable means it can be changed even when called on a const object.
20160809 23:43:29-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160809 23:43:57< vultraz> text_markup = "true" enables markup on text..
20160809 23:44:06< vultraz> but it doesn't like \n
20160809 23:44:08< vultraz> oh well
20160809 23:44:28< vultraz> most of the time it's set to "(text_markup)"
20160809 23:44:40< vultraz> (oh, typo above, I meant tcontrol not tlabel)
20160809 23:44:57< vultraz> tcontrol gets its use_markup_ flag set from various inherited widgets..
20160809 23:45:17< vultraz> and has a 'mutable font::ttext' member
20160809 23:45:25< vultraz> which it calls..
20160809 23:45:48< vultraz> this is independent from gui2::ttext
20160809 23:46:45< vultraz> which keeps a static font::ttext object in its draw() function
20160809 23:46:48< vultraz> this makes no bloody sense
20160809 23:49:03-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Ping timeout: 276 seconds]
20160809 23:51:36< vultraz> oh come ON
20160809 23:51:54< vultraz> a widget cannot have more than 1 linked group specified
20160809 23:51:56< vultraz> are you KIDDING ME
20160809 23:54:08-!- trewe [~trewe@2001:8a0:d118:6301:52e2:38cb:dbe6:c25] has quit [Quit: quit]
20160809 23:54:15< vultraz> someone needs to kick mordante
20160809 23:56:17< celmin> vultraz: Sooo, the unit preview pane has a scrollbar.
20160809 23:56:24< vultraz> YES IT DOES
20160809 23:56:26< celmin> I think this is bad.
20160809 23:56:30< vultraz> NO IT IS NOT
20160809 23:56:50< celmin> Why are you talking in caps?
20160809 23:56:53< vultraz> it's only there if there's not enough space
20160809 23:57:00< vultraz> and i gave it at least 300 
20160809 23:57:01< vultraz> space
20160809 23:57:16< celmin> There should be enough space at least for all core units.
20160809 23:57:16< vultraz> so if it's larger than that AND the dialog doesn't size it larger
20160809 23:57:18< vultraz> it will scroll
20160809 23:57:49< celmin> The large unit image is probably to blame.
20160809 23:58:03< vultraz> you misunderstand
20160809 23:58:10< vultraz> the details area is always at least 300
20160809 23:58:21< celmin> 300 what?
20160809 23:58:35< celmin> I have no idea what this 300 means.
20160809 23:58:42< vultraz> px i guess
20160809 23:58:53< celmin> Wide? High?
20160809 23:58:59< vultraz> high
20160809 23:59:02< vultraz> always at least 225 wide
20160809 23:59:19< vultraz> I confirmed that that width is enough to fit the name of every core unit 
20160809 23:59:32< celmin> 300px is clearly not enough for a druid.
20160809 23:59:32< vultraz> (sizing the details area sizes the rest of the widget too)
20160809 23:59:45< vultraz> experiment with more
20160809 23:59:56< vultraz> it's one line in the WML
--- Log closed Wed Aug 10 00:00:00 2016