--- Log opened Thu Nov 03 00:00:08 2016
20161103 00:00:12< celticminstrel> Well, -stdlib=libc++ does seem to fix it, so the question becomes, how do I make scons pass it.
20161103 00:01:05< loonycyborg> is it supposed to be compile only switch?
20161103 00:01:34< celticminstrel> It should be used for both compiling and linking.
20161103 00:02:15< celticminstrel> (For compiling I guess it sets the include path, for linking it specifies the C++ runtime to link.)
20161103 00:02:45< loonycyborg> CXXFLAGS=-stdlib=libc++ LDFLAGS=-stdlib=libc++ scons
20161103 00:03:03< celticminstrel> So it can't go in the scons options cache huh... :/
20161103 00:03:11< loonycyborg> yup
20161103 00:03:37-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20161103 00:03:37-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20161103 00:03:37-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161103 00:03:41< loonycyborg> I didn't figure out a way of adding such options per build variant without causing a combinatorial explosion
20161103 00:04:24< celticminstrel> So what're the extra_flags_* keys for then...
20161103 00:04:50< loonycyborg> they're fed through scons's ParseConfig logic
20161103 00:05:00< loonycyborg> which expects output from pkg-config
20161103 00:05:09< loonycyborg> it treats unknown flags as compile flags
20161103 00:05:17< loonycyborg> not compile+link
20161103 00:05:22< celticminstrel> But it didn't seem to send it to the compiler either...
20161103 00:05:33< celticminstrel> Maybe I used the wrong key.
20161103 00:05:40 * celticminstrel used _base
20161103 00:06:08< loonycyborg> extra_flags_config
20161103 00:06:12< celticminstrel> Hmm... I wonder, could I add it to the cxxtoll flag?
20161103 00:06:26< celticminstrel> ^cxxtool
20161103 00:06:30< shadowm> I insist that it's should not be the build manager's job to parse compiler flags.
20161103 00:06:34< shadowm> *it
20161103 00:06:50< loonycyborg> the logical way would be to change it to extra_compiler_flags_release etc
20161103 00:06:51 * celticminstrel needed to set that in order to get it to use clang 3.8 instead of Apple's clang ~3.2, anyway
20161103 00:06:59< loonycyborg> but then it'll be too much to type
20161103 00:07:09< celticminstrel> Too much to type?
20161103 00:07:12< loonycyborg> would need to add helpers to generate those options
20161103 00:07:19< celticminstrel> I'd just edit .scons-option-cache.
20161103 00:07:35< loonycyborg> no, I mean in definition in SConstruct
20161103 00:07:40< celticminstrel> Well, it's working for now, anyway.
20161103 00:07:42< celticminstrel> So yay.
20161103 00:08:14< celticminstrel> Even though I said jobs=3 it seems like all four processors are pretty active though...
20161103 00:08:44< shadowm> SCons' itself is quite CPU-intensive.
20161103 00:09:11< shadowm> (was going to say "SCons' dependency checking logic but really am not sure)
20161103 00:09:55< celticminstrel> Well, it's not a big deal.
20161103 00:10:00< celticminstrel> At least it's not in swap hell.
20161103 00:10:12< celticminstrel> Mostly.
20161103 00:10:23< celticminstrel> Less so than when I compile in XCode, certainly.
20161103 00:10:47< loonycyborg> ides eat a lot of mem it seems
20161103 00:11:00< celticminstrel> XCode does, especially with Wesnoth.
20161103 00:11:16< celticminstrel> I can compile BoE or my personal projects without too much trouble even when Firefox is open.
20161103 00:13:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161103 00:49:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 00:49:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161103 00:53:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20161103 01:01:09-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161103 01:08:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161103 01:13:33< celticminstrel> Okay, failed with tons of linker errors...
20161103 01:13:54< celticminstrel> Starting with "_main".
20161103 01:14:29< celticminstrel> ...wait, I think there's actually only three linker errors.3
20161103 01:16:19< vultraz> what are you doing?
20161103 01:16:56< celticminstrel> Compiling with scons on the Mac.
20161103 01:23:09< celticminstrel> loonycyborg: How do I add a source file to just the client? Or just the server?
20161103 01:24:49< celticminstrel> Oh wait, just the server is easy.
20161103 01:25:15< celticminstrel> But not sure on just the client; apparently wesnoth_sources is also used by unit tests.
20161103 01:29:40< celticminstrel> wesnoth_objects maybe?
20161103 01:32:59< shadowm> wesnoth_sources.
20161103 01:33:31< celticminstrel> But if that's also used by the unit tests, it would lead to a duplicate symbol for main...
20161103 01:33:52< shadowm> wesnoth_objects then.
20161103 01:33:59< celticminstrel> Okay.
20161103 01:39:49< celticminstrel> Also need to add libobjc to all three targets...
20161103 01:40:25< celticminstrel> ...not entirely sure if unit tests really need them, but they're including the apple notifications hooks at the moment, so...
20161103 01:43:28 * celticminstrel is currently putting -lobjc in LDFLAGS.
20161103 01:48:13< celticminstrel> I suppose it probably won't produce an app package... but that should be fine...
20161103 01:50:05< celticminstrel> fatal arror: "SDL.h" file not found.
20161103 01:50:21< celticminstrel> Who was it who decided to use quotes instead of angle brackets there.
20161103 01:50:30< celticminstrel> ^error
20161103 01:59:36< celticminstrel> ...hmm, either it works in XCode though, or it's not actually used...
20161103 02:00:24< celticminstrel> It is used though...
20161103 02:01:42< celticminstrel> So why is scons giving an error there (even after changing to <SDL.h>) but not on any other include of SDL...
20161103 02:03:00< celticminstrel> I wonder if we even actually need that file...3
20161103 02:12:55-!- gfgtdf_ [~chatzilla@x4e369d54.dyn.telefonica.de] has joined #wesnoth-dev
20161103 02:15:30-!- Bonobo [~Bonobo@2001:44b8:254:3200:3cc8:d7ca:4d24:b423] has joined #wesnoth-dev
20161103 02:16:09-!- gfgtdf [~chatzilla@x4e363156.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20161103 02:16:20-!- gfgtdf_ is now known as gfgtdf
20161103 02:21:03< celticminstrel> Seems to work without it, so I'll just delete it then.
20161103 03:02:01< celticminstrel> Now ranlib is complaining about files with no symbols... ???
20161103 03:14:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 03:18:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161103 03:22:08-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161103 03:26:19-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161103 03:42:18-!- gfgtdf [~chatzilla@x4e369d54.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]]
20161103 04:10:15< celticminstrel> Hmm, scons was linking Carbon instead of Cocoa. I wonder if fixing that makes -lobjc implicit.
20161103 04:10:35< vultraz> booo carbon
20161103 04:10:50< celticminstrel> I'm guessing people haven't built on Mac with scons for quite awhile.
20161103 04:11:09< vultraz> why are you doing so?
20161103 04:11:18< celticminstrel> Newer compiler.
20161103 04:11:27< celticminstrel> Not sure if I'll make a habit of it though.
20161103 04:11:52< celticminstrel> It's a huge pain to make XCode understand a newer clang, and even then it doesn't work as well as the default.
20161103 04:12:32< vultraz> you really need a new mac :|
20161103 04:13:19< celticminstrel> I do, but I don't really consider it urgent or anything.
20161103 04:15:08-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161103 04:15:52< celticminstrel> Does Wesnoth build with Boost 1.44? Because that seems to be the minimum required by scons.
20161103 04:17:04< vultraz> no idea
20161103 04:17:14< vultraz> I don't think anyone knows what the minimum is.
20161103 04:17:27< shadowm> INSTALL says 1.48.
20161103 04:17:31< vultraz> Yes
20161103 04:17:33< shadowm> You'd think vultraz of all people would know this.
20161103 04:17:34< vultraz> But is that true?
20161103 04:17:54< shadowm> It is true, specifically because previous versions of a library don't provide API we use.
20161103 04:18:07< shadowm> (It is either Boost.Filesystem or Boost.Locale.)
20161103 04:19:28< vultraz> Well, since I don't think we added a usecase for something introduced after that, should be good. The only question is whether our new minimum compiler requirements render that minimum obsolete due to the systems that support said min compiler versions shipping with a newer boost version by default.
20161103 04:19:52< celticminstrel> I didn't understand that convoluted sentence.
20161103 04:20:07< shadowm> I think vultraz is trying to say that the SCons' build requirements are outdated.
20161103 04:20:20< celticminstrel> I'd already gathered that...
20161103 04:20:28< shadowm> And they are, since evidently no-one maintains the SCons recipe anymore.
20161103 04:20:31< shadowm> /s
20161103 04:24:10< shadowm> Okay, now I get it.
20161103 04:24:18< celticminstrel> Well, it's maintained insofar as it works.
20161103 04:24:30 * celticminstrel is updating it now BTW.
20161103 04:24:49< shadowm> vultraz is trying to say that the Boost and compiler version requirements are somehow tied together.
20161103 04:25:02< shadowm> No, they are not unless you are an OS vendor.
20161103 04:25:35< shadowm> There's nothing to stop me from building GCC 6 on a system that has Boost 1.18, for example.
20161103 04:25:40< celticminstrel> Looks like the build succeeded.
20161103 04:25:52< Aginor> I might put a vm together over the weekend in an attempt to make a minimum requirements system
20161103 04:25:58< celticminstrel> Looks like it's working.
20161103 04:26:09< celticminstrel> Huh, it even has its icon somehow.
20161103 04:26:21< Aginor> that features things like boost 1.48, gcc 4.8 etc
20161103 04:26:22< celticminstrel> Oh, wait.
20161103 04:26:28< celticminstrel> Is that still a shell-script...
20161103 04:26:32< Aginor> based on what I read in the INSTALL basically
20161103 04:26:42< Aginor> would people use that if I did?
20161103 04:27:05< vultraz> I recommend 4.9.
20161103 04:27:09< vultraz> But sure,  I suppose.
20161103 04:27:14< celticminstrel> Okay, so where do I find the executable.
20161103 04:27:28< Aginor> vultraz: I will put whatever is in INSTALL on it
20161103 04:27:40< Aginor> I will not take suggestions from IRC into account
20161103 04:27:55< vultraz> fine, fine, do whatever
20161103 04:28:13< celticminstrel> And don't go changing INSTALL to 4.9 BTW
20161103 04:28:22< vultraz> I'm not in the mood to rehash the whole shitty discussion about compiler support and trusty
20161103 04:28:41< celticminstrel> I guess the executable is wesnoth-debug instead of wesnoth.
20161103 04:28:50< vultraz> since apparently travis can't even use xenial yet! so fucking fun.
20161103 04:29:25< celticminstrel> Either it's not working or it's just slow...
20161103 04:29:27< shadowm> There's no need to raise the language bar over such a trivial issue.
20161103 04:29:35< celticminstrel> I did get the warning about SDLApplication, but nothing past that yet...
20161103 04:29:42< vultraz> apologies. 
20161103 04:31:32< celticminstrel> I suppose there could be problems with finding the nib...
20161103 04:35:12< shadowm> Boost.Locale is the reason for the bump to 1.48.
20161103 04:35:54< shadowm> The reason is that 1.48 is the first version to include the library.
20161103 04:37:37< celticminstrel> Uhhh. So it technically works if I copy it into the app bundle that XCode produced, but... the video mode is all confused...
20161103 04:37:54< celticminstrel> Or... it's ignoring my preferences?
20161103 04:38:08< celticminstrel> Hmm, okay, it's probably using a different prefs path I guess...
20161103 04:38:08< shadowm> Not really sure what the best approach wrt SCons would be. 
20161103 04:38:30< celticminstrel> Still, the log says "Setting mode to 1024x768" but instead it's filling the screen.
20161103 04:38:49< celticminstrel> ...huh? Why'd the title screen suddenly change to Loading...
20161103 04:40:39< shadowm> I guess you could just change all versions in the recipe to 1.48.
20161103 04:40:47< celticminstrel> That's what I'd recommend, yeah.
20161103 04:41:12< shadowm>      conf.CheckCPlusPlus(gcc_version = "3.3") & \
20161103 04:41:21< shadowm> No comment.
20161103 04:41:43-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161103 04:43:09< shadowm> Basically, what I'm noticing here is a sync issue between the respective build system maintainers and the general maintainers when it comes to dependencies.
20161103 04:44:00< shadowm> Probably owing to the fact that one of the latter doesn't even use either of the officially-sanctioned build systems.
20161103 04:47:06< celticminstrel> So I need a -D flag to set the userdata and cache dir, right?
20161103 04:47:32< vultraz> eh?
20161103 04:49:14-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161103 04:53:24< shadowm> ... My.
20161103 04:59:22-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161103 05:02:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 05:05:29< shadowm> https://github.com/wesnoth/wesnoth/compare/master...shikadilord:feature/scons-cleanup
20161103 05:07:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161103 05:10:37< celticminstrel> Looks good.
20161103 05:37:09-!- travis-ci [~travis-ci@ec2-54-198-139-146.compute-1.amazonaws.com] has joined #wesnoth-dev
20161103 05:37:10< travis-ci> shikadilord/wesnoth#8 (feature/scons-cleanup - e0bf81e : Ignacio R. Morelle): The build failed.
20161103 05:37:10< travis-ci> Build details : https://travis-ci.org/shikadilord/wesnoth/builds/172839890
20161103 05:37:10-!- travis-ci [~travis-ci@ec2-54-198-139-146.compute-1.amazonaws.com] has left #wesnoth-dev []
20161103 06:03:51-!- travis-ci [~travis-ci@ec2-54-198-139-146.compute-1.amazonaws.com] has joined #wesnoth-dev
20161103 06:03:53< travis-ci> shikadilord/wesnoth#9 (feature/scons-cleanup - c18fce3 : Ignacio R. Morelle): The build failed.
20161103 06:03:53< travis-ci> Build details : https://travis-ci.org/shikadilord/wesnoth/builds/172840759
20161103 06:03:53-!- travis-ci [~travis-ci@ec2-54-198-139-146.compute-1.amazonaws.com] has left #wesnoth-dev []
20161103 06:12:33-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 06:37:53-!- celticminstrel is now known as celmin|sleep
20161103 06:41:56-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161103 06:51:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 06:55:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161103 07:02:31-!- JyrkiVesterinen [~JyrkiVest@87-100-135-124.bb.dnainternet.fi] has joined #wesnoth-dev
20161103 07:03:24< JyrkiVesterinen> 20161102 21:55:46< vultraz> jyrki: (if you read logs) please submit your fixed sized chatbox pr by saturday so i can look at it
20161103 07:03:44< JyrkiVesterinen> I can't promise anything. The size_lock widget still isn't fully functional.
20161103 07:04:18< JyrkiVesterinen> The widget allocates the size that I specify, but the widget inside it doesn't span to that size.
20161103 07:04:44< JyrkiVesterinen> I plan to look at that problem tomorrow, but there may well be even more bugs in it.
20161103 07:05:19< JyrkiVesterinen> Besides, I dislike the idea of trying to rush changes into a release. That's exactly how you get buggy releases.
20161103 07:16:36-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20161103 07:24:24-!- JyrkiVesterinen [~JyrkiVest@87-100-135-124.bb.dnainternet.fi] has quit [Quit: Going to work]
20161103 07:39:33< vultraz> jyrki: see comment on the pr
20161103 07:39:37< vultraz> jyrki: er, commit
20161103 07:39:39< vultraz> sorry
20161103 07:56:53< Aginor> 20:05 < JyrkiVesterinen> Besides, I dislike the idea of trying to rush changes into a release. That's exactly how you get buggy releases.
20161103 07:56:57< Aginor> +1 :)
20161103 07:57:15 * vultraz looks sideways
20161103 07:57:44< vultraz> ¬_¬
20161103 07:59:46< vultraz> though i have not observed the symptoms in the chatbox he described, i don't like the idea of pushing the new ui stuff with that
20161103 07:59:57< vultraz> being a potential issue
20161103 08:00:25< Aginor> we shouldn't be pushing new stuff this close to a release, we should be testing and fixing bugs
20161103 08:02:06< vultraz> it is a bugfix
20161103 08:02:08< vultraz> of a sort :)
20161103 08:14:06-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has joined #wesnoth-dev
20161103 08:27:54< Aginor> vultraz: where's the darkening of items happening in the listbox(?) that's used for the campaign selector?
20161103 08:29:23< vultraz> Aginor: https://github.com/wesnoth/wesnoth/blob/master/data/gui/widget/toggle_panel_default.cfg#L39
20161103 08:29:30< vultraz> i assume that's what you mean
20161103 08:30:01< Aginor> no, not really, that's not in the c++ code
20161103 08:30:20< vultraz> you'll have to elaborate more.
20161103 08:31:23< Aginor> there's c++ code that's responsible for drawing the darkening of that list widget thing that's used for the campaign selector
20161103 08:31:29< Aginor> do you know what/where it may be?
20161103 08:32:32< vultraz> The list is made up of multiple toggle panels. The toggle panel widget's wml tells it to fill the widget with a rectangle the size of itself with the color "0, 0, 0, 89"
20161103 08:33:00< vultraz> rectangle drawing is here https://github.com/wesnoth/wesnoth/blob/master/src/gui/core/canvas.cpp#L710
20161103 08:33:46< Aginor> so it's not an actual widget that's used there?
20161103 08:34:02< vultraz> canvas drawing for each widgets is handled by each one's impl_draw_background/impl_draw_foreground methods
20161103 08:34:19< vultraz> Aginor: the tint is a canvas effect that's part of a widget
20161103 08:34:33< vultraz> I'm not sure what you mean by "not an actual widget"
20161103 08:34:44< Aginor> widget class
20161103 08:34:51< Aginor> or am I misunderstanding you?
20161103 08:34:54< vultraz> uh...
20161103 08:35:10< vultraz> each "widget" has both a c++ and wml counterpart
20161103 08:35:16< vultraz> the wml defines how it actually looks
20161103 08:35:46< Aginor> so colours?
20161103 08:35:58< vultraz> yes
20161103 08:36:03< Aginor> ok
20161103 08:36:03< vultraz> all of that is in the wml
20161103 08:36:07< vultraz> in data/gui/widget
20161103 08:36:17< Aginor> I care about the backing implementation though
20161103 08:36:29< Aginor> and where it's defined what sub-components a widget may have
20161103 08:36:40< vultraz> in this case, it's a [rectangle]
20161103 08:36:46< vultraz> which is a canvas shape
20161103 08:36:56< vultraz> which is handled in canvas.cpp
20161103 08:37:05< vultraz> and again, [19:34:02]	vultraz	canvas drawing for each widgets is handled by each one's impl_draw_background/impl_draw_foreground methods
20161103 08:37:30< Aginor> yes...
20161103 08:38:35< vultraz> the "master" drawing routines are twidget::draw_background, twidget::draw_children, and twidget::draw_foreground
20161103 08:38:41< vultraz> which are all called in twindow::draw()
20161103 08:39:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 08:39:29< Aginor> ok, thanks
20161103 08:39:45< vultraz> each widget's  impl_draw_background/impl_draw_foreground deals with all the canvases a widget may have
20161103 08:40:13< vultraz> and again, the actual rendering happens in canvas.*cpp
20161103 08:40:36< Aginor> I'm trying to track down what's going on with that rendering
20161103 08:40:44< Aginor> because something isn't stacking up here
20161103 08:42:26< vultraz> btw, as far as i can tell twindow::draw passes around a single surface reference to all functions
20161103 08:42:31< vultraz> which it gets from video_.getSurface();
20161103 08:42:45< Aginor> good
20161103 08:42:51< Aginor> or wesnoth will crash
20161103 08:43:28< vultraz> the whole thing has a few issues
20161103 08:43:55< vultraz> that weird blur bug, you know of :)
20161103 08:44:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161103 08:44:06< Aginor> no, I don't
20161103 08:44:52< vultraz> https://github.com/wesnoth/wesnoth/blob/master/src/gui/core/canvas.cpp#L1462-L1477
20161103 08:45:21< Aginor> I still don't know about it
20161103 08:45:22< vultraz> come to think of it, it's probably something similar that causes https://gna.org/bugs/index.php?25107 ...
20161103 08:45:41< vultraz> well, whatever
20161103 08:45:54< vultraz> suffice to say the workflow has a few bugs
20161103 08:46:08< vultraz> would be better if everything were done with dirty rects but oh well
20161103 08:48:53-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has joined #wesnoth-dev
20161103 08:54:32< shadowm> celmin|sleep: I can't merge those changes. Seems SCons is using the GCC version value provided in CheckCPlusPlus() when testing Clang somehow.
20161103 08:56:01< shadowm> Since I'm not up for debugging SCons remotely through travis, I guess I'll have to install clang again. *sigh*
20161103 09:00:39< shadowm> *sigh* Why can't this thing honor SIGINT?
20161103 09:01:19< shadowm> This is supposed to be superior to CMake somehow: http://pastebin.com/raw/NgQRXU46
20161103 09:03:07< shadowm>     if gcc_version and "gcc" in context.env["TOOLS"]:    <check GCC version in the config test using #if>
20161103 09:03:30< shadowm> Apparently `"gcc" in context.env["TOOLS"]` yields true when cxxtool=clang++-3.9.
20161103 09:03:31-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161103 09:03:39< shadowm> For some reason.
20161103 09:31:16-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 10:26:37-!- irker054 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161103 10:26:37< irker054> wesnoth: ln-zookeeper wesnoth:master a86d5f1e36a2 / data/core/terrain-graphics/new-macros.cfg: Fixed NEW:WALL2_P ignoring the probability argument https://github.com/wesnoth/wesnoth/commit/a86d5f1e36a29223677cfcd1d69d64a305699f31
20161103 10:27:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 10:31:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 245 seconds]
20161103 10:32:11< irker054> wesnoth: ln-zookeeper wesnoth:master cf5f6bab3687 / data/core/terrain-graphics.cfg: Avoid unnecessary and invisible desert mountain -> walls transitions https://github.com/wesnoth/wesnoth/commit/cf5f6bab36877bd1b607ebe5168f5977c54333b9
20161103 10:35:11-!- Nikitaw99 [2e004800@gateway/web/freenode/ip.46.0.72.0] has joined #wesnoth-dev
20161103 10:35:19< Nikitaw99> hi
20161103 10:35:51< Nikitaw99> how do I activate debug mode, and what can i do in debug mode?
20161103 10:37:03< vultraz> you type ";debug" (in 1.13) or ":debug" (in 1.12) in-game
20161103 10:37:28< vultraz> it allows you access to certain helpful commands mostly used when developing user made content
20161103 10:37:45< vultraz> like skipping to later levels in a campaign, creating units, or changing their stats.
20161103 10:38:01< Nikitaw99> does it have a page on the wiki?
20161103 10:38:24< Nikitaw99> and if so, please give me a link to it.
20161103 10:39:54< loonycyborg> shadowm: there's no separate value of env["TOOLS"] for clang. Because clang can take same options as gcc :P
20161103 10:44:01< JyrkiVesterinen> Nikitaw99: https://wiki.wesnoth.org/CommandMode
20161103 10:44:18< Nikitaw99> JyrkiVesterinen: Thank you very much.
20161103 10:44:23< JyrkiVesterinen> Yw :)
20161103 10:53:25< loonycyborg> shadowm: that test program is defined in scons/ cplusplus.py
20161103 10:53:48< loonycyborg> It's checking for __GNUC__
20161103 10:53:54< loonycyborg> and afaik clang defines it too
20161103 10:53:58< loonycyborg> for compatibility
20161103 10:55:52< JyrkiVesterinen> Indeed, Clang #defines __GNUC__.
20161103 10:56:24< JyrkiVesterinen> I find that doing so only causes compatibility *problems*, such as shadowm's problem here, or this: https://github.com/wesnoth/wesnoth/commit/2cc92e881ed035e4403daaea5c06f7fd8573c6a5
20161103 10:56:28 * JyrkiVesterinen sighs 
20161103 11:10:36< loonycyborg> anyway, since clang emulates gcc the best way is to treat it as gcc with occasional special cases for clang
20161103 11:12:05< loonycyborg> and that test program could be changed to have tests both gcc and clang checking for __clang__ and __GNUC__
20161103 11:12:10-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161103 11:18:51< zookeeper> behold!
20161103 11:18:53< irker054> wesnoth: ln-zookeeper wesnoth:master f91cfef9cbb5 / / (4 files in 3 dirs): Made castles and keeps properly connect with adjacent walls https://github.com/wesnoth/wesnoth/commit/f91cfef9cbb5fabedca08eecf968e55b4f5271d3
20161103 11:20:11< zookeeper> there's only relatively few cases where it doesn't really work
20161103 11:20:29< zookeeper> but it covers the vast majority
20161103 11:47:58-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161103 12:04:30-!- Bonobo [~Bonobo@2001:44b8:254:3200:3cc8:d7ca:4d24:b423] has quit [Quit: Leaving]
20161103 12:11:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161103 12:16:10-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161103 12:16:35-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161103 12:18:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20161103 12:57:45-!- travis-ci [~travis-ci@ec2-54-198-117-233.compute-1.amazonaws.com] has joined #wesnoth-dev
20161103 12:57:46< travis-ci> spixi/wesnoth#16 (chart_engine - bda8426 : Spixi): The build has errored.
20161103 12:57:47< travis-ci> Build details : https://travis-ci.org/spixi/wesnoth/builds/172925305
20161103 12:57:47-!- travis-ci [~travis-ci@ec2-54-198-117-233.compute-1.amazonaws.com] has left #wesnoth-dev []
20161103 13:08:47-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161103 13:18:03< DeFender1031> celmin|sleep, (or anyone else really), all the metatable creation functions, is there a reason why you need to pass them a table to use? can't they just create a new table internally, set the metatable on that, and return it?
20161103 13:25:06-!- stikonas_ is now known as stikonas
20161103 13:30:23-!- prkc [~prkc@46.166.137.238] has joined #wesnoth-dev
20161103 13:35:03< DeFender1031> for example, is there a reason helper.set_wml_tag_metatable takes an argument instead of bing written as such: http://paste.nachsoftware.com/DeFender1031/TlPYVK3527dbfcc2adc268675581b3cf0c84cajm
20161103 13:35:13< DeFender1031> being*
20161103 13:54:27-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 13:55:56-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 268 seconds]
20161103 13:56:09-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20161103 13:56:09-!- wedge010 is now known as wedge009
20161103 13:58:06-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161103 13:58:23-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 14:01:09-!- gfgtdf [~chatzilla@x4e369d54.dyn.telefonica.de] has joined #wesnoth-dev
20161103 14:01:24< gfgtdf> DeFender1031: not that i know of
20161103 14:02:06< gfgtdf> DeFender1031: but since "local a = helper.set_wml_tag_metatable()" istn less to type than "local a = helper.set_wml_tag_metatable {}" i dont think this is an issue
20161103 14:02:35< gfgtdf> DeFender1031: if you want you can chang it to "return setmetatable(t or {}, create_tag_mt)"
20161103 14:04:13< DeFender1031> gfgtdf, true enough. I was thinking of that actually, but right now i'm working on that function list for celmin, and i'm proposing (as part of it) a rename of those tables from "set_whatever_metatable" to "get_whatever_metatable", since that's really what you're trying to accomplish with the function.
20161103 14:06:10< gfgtdf> DeFender1031: well this doesnt really return the meatable. Also this woudl brka evry adon for no real gain.
20161103 14:08:02< DeFender1031> 1. it returns a table which uses it 2. so would the rest of the reorganization i'm proposing, there'd be temporary deprecated aliases from the old places pointing to the new, so that's not an issue.
20161103 14:08:39< DeFender1031> though about #1, you're right, perhaps "get proxy" is a better name.
20161103 14:19:19-!- irker054 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161103 14:30:24-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has quit [Ping timeout: 252 seconds]
20161103 14:40:26-!- boucman_work [~boucman@82.237.199.7] has joined #wesnoth-dev
20161103 14:54:14-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161103 15:00:13-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161103 15:21:10-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161103 15:35:32-!- Appleman1234 [~Appleman1@KD106161198196.au-net.ne.jp] has quit [Ping timeout: 244 seconds]
20161103 15:41:28-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection]
20161103 15:43:55-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161103 15:45:11-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds]
20161103 15:52:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 16:00:57< shadowm> loonycyborg: What is env["TOOLS"] in the first place?
20161103 16:01:45< loonycyborg> list of loaded tool modules
20161103 16:01:56< loonycyborg> on linux it'll contain "gcc"
20161103 16:02:19-!- gfgtdf [~chatzilla@x4e369d54.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]]
20161103 16:02:24< shadowm> Okay, so another stupid SCons thing related to trying to guess how compilers work.
20161103 16:02:49< shadowm> I'll read up on clang's defines then.
20161103 16:08:03-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 16:14:14-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has quit [Quit: .]
20161103 16:15:02-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 16:15:20-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 16:17:47< celmin|sleep> ...
20161103 16:17:54< celmin|sleep> What the heck.
20161103 16:18:05< celmin|sleep> How can I tell it to use a prefsdir with spaces in it...
20161103 16:18:13< vultraz> what are you doing?
20161103 16:20:33< vultraz> zookeeper: were dwrarven castle excluded deliberately?
20161103 16:23:08< celmin|sleep> [Nov 03@05:00:39am] shadowm: *sigh* Why can't this thing honor SIGINT?
20161103 16:23:09< celmin|sleep> Yeah, I was wondering that too. ><
20161103 16:23:10< celmin|sleep> DeFender1031: I've wondered about the need to pass a table to the metatable functions too... I don't know of any reason.
20161103 16:23:12< celmin|sleep> vultraz: Still scons.
20161103 16:23:16 * celmin|sleep poke loonycyborg 
20161103 16:23:45< loonycyborg> about spaces?
20161103 16:23:52< loonycyborg> "" should be enough afaik
20161103 16:25:07< loonycyborg> sigint only does bad things for configure phase
20161103 16:25:18< loonycyborg> it seems configure stuff doesn't handle it well
20161103 16:26:16< shadowm> loonycyborg: Also clang most decidedly can't take allthe same options as gcc.
20161103 16:26:41< loonycyborg> it tries though :P
20161103 16:26:56< shadowm> loonycyborg: Firstly, there are options clang supports that gcc doesn't (such as -Qunused-arguments).
20161103 16:27:28< shadowm> loonycyborg: Secondly, until version 3.9 or 4.0 (not sure which) clang doesn't support GCC's ABI tags feature, and I believe there is a command line switch related to it in GCC.
20161103 16:28:05< shadowm> loonycyborg: Thirdly, any time GCC adds a new option it doesn't necessarily have to be immediately supported by GCC (and viceversa). That's simply impossible.
20161103 16:28:28< celmin|sleep> It doesn't seem to accept SIGINT even after configure phase though...
20161103 16:28:31< shadowm> This is why playing compiler catch-up is honestly stupid.
20161103 16:28:55< DeFender1031> celmin|sleep, then in my proposed rename list, i'm going to propose that they get renamed to some version of "get_proxy", and still optionally take a table for backwards compat during whatever deprecation period for the old names, but will generate one automatically if not passed and deprecate being able to pass one at all, to be removed in a future version.
20161103 16:28:57< shadowm> Both for compilers themselves, and tools that second-guess compiler input.
20161103 16:29:31< celmin|sleep> Anyway, I have prefsdir='/path/to my/prefsdir' and it produces "-DPREFERENCES_DIR='"/path/to my/prefsdir"'" on the command-line. All those quotes indluced.
20161103 16:29:34< celmin|sleep> ^included
20161103 16:30:09< loonycyborg> hmm
20161103 16:30:24< loonycyborg> shouldn't quotes be discarded by shell such as bash?
20161103 16:30:53-!- celmin|sleep is now known as celticminstrel
20161103 16:31:56-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 16:32:21-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 16:33:36-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20161103 16:36:03< DeFender1031> celticminstrel, does what i said make sense
20161103 16:36:04< DeFender1031> ?
20161103 16:38:31< celticminstrel> Yeah.
20161103 16:39:13-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161103 16:40:18< celticminstrel> loonycyborg: They are discarded, of course. However, notice that there are two sets of double quotes... so the quotes aren't actually protecting the spaces.
20161103 16:40:36-!- gfgtdf [~chatzilla@x4e369d54.dyn.telefonica.de] has joined #wesnoth-dev
20161103 16:43:22-!- Appleman1234 [~Appleman1@KD106161198196.au-net.ne.jp] has joined #wesnoth-dev
20161103 16:44:16< loonycyborg> celticminstrel: hmm I'll try it myself
20161103 16:46:06< celticminstrel> The inner pair of double quotes needs to be literal.
20161103 16:46:47< celticminstrel> It would work as is if the outer pair wasn't added.
20161103 16:47:19< celticminstrel> But with the outer pair you'd need to use \" instead surrounding the path in single quotes.
20161103 16:49:09< celticminstrel> Seems like scons stupidly adds the outer quotes on its own.
20161103 16:49:09< shadowm> Nikitaw99: Re https://forums.wesnoth.org/viewtopic.php?p=604546#p604546 please don't resurrect dead topics with just that.
20161103 16:50:10< shadowm> Nikitaw99: It's very obvious that all links in the thread are outdated and dead and the author hasn't been around for 7 years.
20161103 16:50:20< zookeeper> vultraz, dwarven castles already have special connecting tiles
20161103 16:51:39< Nikitaw99> well, https://wiki.wesnoth.org/ExternalUtilities needs cleaning up.
20161103 16:52:09< celticminstrel> ...what happened to Dugi's Code Contributor title?
20161103 16:52:11< shadowm> Anyone with a wiki account can do that.
20161103 16:53:20< shadowm> That whole page seems horrendously out of date.
20161103 16:54:28< shadowm> celticminstrel: Some things are the sole domain of the forum administration I'm afraid.
20161103 16:57:27< shadowm> Sigh: http://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros
20161103 16:57:36< shadowm> " Note that marketing version numbers should not be used to check for language features, as different vendors use different numbering schemes. Instead, use the Feature Checking Macros."
20161103 16:57:48< celticminstrel> That's completely true.
20161103 16:57:50< shadowm> Well, in that case I can just exclude clang from version checks.
20161103 16:58:02< shadowm> Yes, I've noticed the truthfulness of that statement before.
20161103 16:58:23< shadowm> e.g. OS X people here reporting weird version numbers like clang 5.0 or so.
20161103 16:58:27< celticminstrel> I'm using the feature checking macros in global.hpp already though.
20161103 16:58:35< celticminstrel> I think Apple clang uses the XCode version.
20161103 16:59:05< shadowm> Is there anything special about it other than the fact that it's shipped with XCode?
20161103 16:59:11< shadowm> Out of curiosity.
20161103 16:59:36< celticminstrel> I'm not quite sure, but I would guess it has some extra features or options that vanilla clang does not have.
20161103 16:59:38< loonycyborg> celticminstrel: it seems that it's automatic behavior, it's adding "" if it sees spaces
20161103 17:00:15< celticminstrel> loonycyborg: Changing line 57 of src/SConscript to filesystem_env.Append(CPPDEFINES = "PREFERENCES_DIR=\\\"$prefsdir\\\"") makes it work.
20161103 17:00:15< shadowm> And thanks to its licensing they don't need to release those changes or confirm that they even exist. Greeeat.
20161103 17:00:58< celticminstrel> I wouldn't be surprised if that's one of their reasons for switching from gcc to clang.
20161103 17:01:20< loonycyborg> hmm cool, but I remember there were trouble on windows with this
20161103 17:01:39< shadowm> celticminstrel: Yeah, it most certainly is.
20161103 17:01:51< celticminstrel> ...good point. I'm not sure whether it would work on Windows.
20161103 17:02:05< shadowm> It's also why MS has shown interest in clang as of late.
20161103 17:02:27< celticminstrel> Huh, that's kinda surprising.
20161103 17:02:42 * celticminstrel already got clang working in MSVC 2013. (Not for Wesnoth though.)
20161103 17:03:22< celticminstrel> Okay, looks like this build works now and uses the same prefs as the XCode build.
20161103 17:03:42< celticminstrel> I won't commit that line 57 thing unless someone can confirm that it works on Windows.
20161103 17:04:20< celticminstrel> Well, it crashed on stoi, huh...
20161103 17:08:05< Soliton> "PREFERENCES_DIR=\\\"$prefsdir\\\"" would be correct if there is another eval before the shell gets that. i.e. the shell then gets: PREFERENCES_DIR="$prefsdir"
20161103 17:08:36< celticminstrel> Does the shell treat those quotes as literal?
20161103 17:08:45< celticminstrel> I wouldn't've expected it to.
20161103 17:09:05< Soliton> no, those should be syntactic quotes.
20161103 17:09:15< celticminstrel> No, the compiler needs them.
20161103 17:09:23< celticminstrel> It's defining the symbol to be a string constant.
20161103 17:09:24< Soliton> oh, i see.
20161103 17:09:49< Soliton> then what's currently there seems fine.
20161103 17:10:05< celticminstrel> And my alteration is not?
20161103 17:10:55< Soliton> if the expectation is that something adds quotes around the whole thing then yours would be fine.
20161103 17:11:22< Soliton> (double quotes)
20161103 17:12:06< Soliton> which was what you reported it seems.
20161103 17:12:12< celticminstrel> Yeah.
20161103 17:13:13< Soliton> "PREFERENCES_DIR=$prefsdir"  should work as well then.
20161103 17:13:49< celticminstrel> But that wouldn't add the string quotes would it?
20161103 17:14:06< Soliton> right, forgot about those again...
20161103 17:14:25< Soliton> so yeah, need to escape those like you did.
20161103 17:16:13< celticminstrel> So my build is crashing from an std::invalid_argument thrown at line 87 of tod_manager.cpp... which should be caught...
20161103 17:16:22< celticminstrel> There's a catch clause so why is it not being caught...
20161103 17:21:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20161103 17:21:31< celticminstrel> ...that lambda is unnecessary, too.
20161103 17:22:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 17:24:32-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161103 17:25:07< celticminstrel> vultraz: Please don't make lambdas that do nothing but "return f(x)".
20161103 17:25:08< shadowm> loonycyborg: What's the point of the compiler version check if SCons will carry on and waste time trying to test libraries anyway?
20161103 17:25:35< celticminstrel> You can just pass f as the function directly.
20161103 17:25:38< shadowm>     Checking whether C++ compiler works (g++ version >= 4.8 required)... no
20161103 17:25:41< shadowm>     Checking for Boost iostreams library version >= 1.48.0... yes
20161103 17:25:51< shadowm> (Pointed it to GCC 4.4.)
20161103 17:25:56< vultraz> celticminstrel: what now?
20161103 17:25:58< vultraz> where
20161103 17:26:08< loonycyborg> well, I don't mind dropping compiler version check
20161103 17:26:27< celticminstrel> I think it does at least count as a failure and not continue with the actual build though.
20161103 17:26:34< celticminstrel> But you have a point.
20161103 17:26:55< vultraz> zookeeper: hm?
20161103 17:27:09< celticminstrel> vultraz: I mentioned the line earlier, 87-ish in tod_manager.cpp
20161103 17:27:21< celticminstrel> Hmm.
20161103 17:27:25< shadowm> loonycyborg, vultraz: No, it does continue with the actual build, in a way, but then it poops itself.
20161103 17:27:37< shadowm> http://pastebin.com/raw/reFdSeSB
20161103 17:27:43< zookeeper> vultraz, well just look and see. that's how dwarven castles have more or less always worked.
20161103 17:27:53< shadowm> Notice the output after "applying configuration".
20161103 17:27:56< celticminstrel> vultraz: But don't go changing it now.
20161103 17:29:12< vultraz> celticminstrel: the lambda seems reasonable... how else would it be done? and anyway, that's not my code
20161103 17:29:25< celticminstrel> Ah, looks like it's needed in this case because stoi has optional arguments. :/
20161103 17:29:35< shadowm> You could bind it.
20161103 17:29:44< celticminstrel> If that were not the case you could do transform(begin(), end(), begin(), std::stoi)
20161103 17:29:51< celticminstrel> shadowm: True, but vultraz seems to hate bind.
20161103 17:30:02< shadowm> I tend to agree that bind isn't the most readiy
20161103 17:30:05< shadowm> ...
20161103 17:30:07< celticminstrel> Not worth changing it now, anyway.
20161103 17:30:13< shadowm> I tend to agree that bind isn't the most readable approach.
20161103 17:30:13< vultraz> I don't hate bind :|
20161103 17:30:19< vultraz> I use bind when it's necessary
20161103 17:30:24-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161103 17:30:27< celticminstrel> Well you give the impression of hating it...
20161103 17:30:35< vultraz> I just prefer lambdas for their readability 
20161103 17:30:44-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 17:31:06< vultraz> and will usually pick a lambda over bind
20161103 17:31:10< vultraz> if possible
20161103 17:31:37< celticminstrel> But before deciding whether to pick a lambda or bind you should consider whether you can just pass an existing function.
20161103 17:31:43< vultraz> of course
20161103 17:32:29< celticminstrel> So I'm hoping that catching by reference will fix this,
20161103 17:32:34< vultraz> but again
20161103 17:32:35< celticminstrel> But I'm not too hopeful...
20161103 17:32:38< vultraz> this is not my code
20161103 17:33:05< celticminstrel> Are you sure? Maybe it's not, but you are the one who made everything use stoi and then dealt with catching exceptions from it.
20161103 17:33:10< vultraz> zookeeper: yes, but we don't want the cave transitions with walls :/
20161103 17:33:18< celticminstrel> So maybe it is.
20161103 17:33:48-!- Appleman1234 [~Appleman1@KD106161198196.au-net.ne.jp] has quit [Ping timeout: 245 seconds]
20161103 17:34:11-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 17:34:50< celticminstrel> vultraz: What are you talking about? Why would you know want cave transitions with walls?
20161103 17:35:03-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 245 seconds]
20161103 17:35:04-!- wedge010 is now known as wedge009
20161103 17:35:05< celticminstrel> Though I'm not 100% sure what that means.
20161103 17:35:27< vultraz> celticminstrel: dwarven castles still use their cave wall transition images with stone walls, even after zookeeper's change
20161103 17:35:38< vultraz> that's undesirable. 
20161103 17:35:59< celticminstrel> Oh, so what's undesirable is the choice of transitions, not the existence of them.
20161103 17:36:05< celticminstrel> ^not want
20161103 17:36:27< vultraz> yes
20161103 17:36:37< vultraz> celticminstrel: tha lambda was introduced in 531e05af9e2f8feaf036b0d4fed89ae6c44b51da
20161103 17:36:40< vultraz> that*
20161103 17:36:58< vultraz> by jyrki
20161103 17:37:22< celticminstrel> Ah, okay.
20161103 17:37:36< celticminstrel> Fair enough.
20161103 17:39:08< gfgtdf> does anyone know why https://github.com/wesnoth/wesnoth/blob/master/src/scripting/game_lua_kernel.cpp#L3779 adds a changes reports_ ? Note that this is the getter functiomn not the setter.
20161103 17:42:36< zookeeper> vultraz, oh "stone walls". you should have said so
20161103 17:42:50< vultraz> zookeeper: what did you think I meant :/
20161103 17:42:51< zookeeper> yeah i forgot that, shouldn't be hard to add
20161103 17:42:54< zookeeper> vultraz, walls
20161103 17:44:04-!- boucman_work [~boucman@82.237.199.7] has quit [Remote host closed the connection]
20161103 17:45:59< vultraz> zookeeper: should just be removing an inclusion/adding an exclusion rule, I'd think?
20161103 17:50:58-!- travis-ci [~travis-ci@ec2-54-198-117-233.compute-1.amazonaws.com] has joined #wesnoth-dev
20161103 17:50:59< travis-ci> shikadilord/wesnoth#10 (feature/scons-cleanup - c2a25b6 : Ignacio R. Morelle): The build was fixed.
20161103 17:51:00< travis-ci> Build details : https://travis-ci.org/shikadilord/wesnoth/builds/173017525
20161103 17:51:00-!- travis-ci [~travis-ci@ec2-54-198-117-233.compute-1.amazonaws.com] has left #wesnoth-dev []
20161103 17:52:55-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 17:54:53 * celticminstrel has no idea about what gfgtdf said.
20161103 17:55:29< celticminstrel> Although...
20161103 17:55:41< celticminstrel> If the return value is a mutable table, it could make sense?
20161103 17:55:46-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 17:56:27< zookeeper> vultraz, dunno yet
20161103 17:57:33< vultraz> well, this is a fun corner case bug :|
20161103 17:57:47-!- TC03 [~quassel@venus.arosser.com] has quit [Ping timeout: 250 seconds]
20161103 17:57:52< vultraz> wesnoth will freeze if you go into the editor, open Help, then try to quit to titlescreen
20161103 17:58:00< vultraz> it will not freeze if you don't open help
20161103 17:58:14-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161103 17:58:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 17:58:35< celticminstrel> Looks like it returns a closure though, so I guess that doesn't make sense.
20161103 17:59:01< celticminstrel> Or a function at least.
20161103 17:59:48-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20161103 18:01:41-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20161103 18:01:54< mordante> servus
20161103 18:04:36< gfgtdf> hi
20161103 18:04:44-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161103 18:12:00-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 18:12:15-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 18:16:31-!- JyrkiVesterinen [~JyrkiVest@78-27-98-26.bb.dnainternet.fi] has joined #wesnoth-dev
20161103 18:16:59-!- gfgtdf_ [~chatzilla@x4e369d54.dyn.telefonica.de] has joined #wesnoth-dev
20161103 18:19:13-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 18:19:21-!- gfgtdf [~chatzilla@x4e369d54.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20161103 18:19:23-!- gfgtdf_ is now known as gfgtdf
20161103 18:19:31-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 18:26:19< JyrkiVesterinen> 20161103 17:29:25< celticminstrel> Ah, looks like it's needed in this case because stoi has optional arguments. :/
20161103 18:26:48< JyrkiVesterinen> Indeed. I originally tried std::bind() there, but it didn't compile because the compiler can't tell which overload I intended to use.
20161103 18:28:49< celticminstrel> The exception still isn't being caught somehow with my build.
20161103 18:28:55< celticminstrel> (scons build)
20161103 18:30:35< celticminstrel> I don't understand how this is possible.
20161103 18:31:11< celticminstrel> Unless two different versions of the C++ runtime are present...
20161103 18:31:43< JyrkiVesterinen> Maybe some kind of ABI compatibility problem, where your build of Wesnoth disagrees with itself about how exception handling works...
20161103 18:33:20< celticminstrel> Hmm, all the libs except Boost and libc++ seem to be referenced in /opt/local, but Boost is referenced without a path and libc++ is in /usr/lib...
20161103 18:33:32< celticminstrel> ^/opt/local/lib
20161103 18:34:15-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 18:34:18< celticminstrel> I don't see a libc++ in /opt/local/lib though...
20161103 18:34:59< celticminstrel> (Also surely it should reference Boost from there too... I think the lack of a path indicates it's using the one I built myself, which is in /usr/local/lib.)
20161103 18:36:32-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161103 18:38:16< celticminstrel> Well, it doesn't seem like there'd be two different libc++ being linked, since there's only the one present.
20161103 18:39:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161103 18:40:16< celticminstrel> I can install a later libc++ through MacPorts, but I get the impression that that'd cause more problems than it solves.
20161103 18:41:08< celticminstrel> Boost isn't even involved in this particular place.
20161103 18:41:26< celticminstrel> So I guess it's not something wrong with Boost...
20161103 18:42:11< celticminstrel> Oh wait, if it's something about the compiler actually implementing exceptions differently, then... I guess using a newer libc++ would be the only option?
20161103 18:42:59< JyrkiVesterinen> I'm quite sure that Clang would refuse to build with a too old version of libc++.
20161103 18:43:18< celticminstrel> But if I do that I need to make sure that the Boost is linked to the same libc++.
20161103 18:43:43< celticminstrel> And I think that would end up being a huge pain.
20161103 18:44:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 18:44:51< celticminstrel> ...I do recall exception breakpoints in XCode being on a symbol "__cxa_throw" or something, and trying to set a breakpoint there didn't work with this build... no idea if that's relevant.
20161103 18:46:09< celticminstrel> Well anyway, I should probably push the scons updates I've done so far.
20161103 18:47:02< celticminstrel> It might not quite work for me, but I bet it would work for someone using newer XCode.
20161103 18:47:22< celticminstrel> (And it does actually work for me except for some of the exception handling.)
20161103 18:47:37-!- irker865 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161103 18:47:37< irker865> wesnoth: Celtic Minstrel wesnoth:master 535fe6b35dcb / projectfiles/Xcode/ (Mac Sources/Wesnoth_Prefix.pch Wesnoth.xcodeproj/project.pbxproj): XCode: Remove unused prefix header https://github.com/wesnoth/wesnoth/commit/535fe6b35dcb72260a5ce521371b83c58663a36e
20161103 18:47:37< irker865> wesnoth: Celtic Minstrel wesnoth:master 551eb507f7aa / / (7 files in 4 dirs): Move Mac-specific sources into main source tree and include in scons build https://github.com/wesnoth/wesnoth/commit/551eb507f7aa8efdcae6360a27f11896208a8fce
20161103 18:47:38< irker865> wesnoth: Celtic Minstrel wesnoth:master ffe9182fb3e0 / SConstruct: scons: Mac builds should link Cocoa, not Carbon https://github.com/wesnoth/wesnoth/commit/ffe9182fb3e072a08c7ffeae453969dd7d4f4da1
20161103 18:47:38< irker865> wesnoth: Celtic Minstrel wesnoth:master b7ee27c8e79d / src/SConscript: scons: Fix build failure when prefsdir contains spaces https://github.com/wesnoth/wesnoth/commit/b7ee27c8e79d8b136655a3a50831ff77aa0bc5f2
20161103 18:47:42< celticminstrel> (I mean, the build compiles, links, and even runs.)
20161103 18:47:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161103 18:47:48< celticminstrel> JyrkiVesterinen: Really?
20161103 18:47:53-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
20161103 18:48:03< celticminstrel> Well... this is clang 3.8 but the libc++ is from around 3.2.
20161103 18:48:11-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20161103 18:48:18< celticminstrel> (clang 3.2, I dunno the libc++ version.)
20161103 18:48:34< celticminstrel> (Maybe they're the same.)
20161103 18:48:38< JyrkiVesterinen> I mean, it would be just stupid to allow the compiler to generate completely broken builds.
20161103 18:48:49< celticminstrel> Right.
20161103 18:49:02< celticminstrel> I can get to the titlescreen but it crashes when I start a game.
20161103 18:49:16< celticminstrel> Due to an uncaught exception that according to the code is being caught.
20161103 18:49:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20161103 18:51:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 18:52:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20161103 18:58:39-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161103 18:58:45-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161103 19:04:24-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161103 19:04:24-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20161103 19:05:11-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161103 19:05:34-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 19:06:52-!- wedge010 is now known as wedge009
20161103 19:10:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161103 19:16:30< irker865> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox 8a0af227194d / / (8 files in 3 dirs): WIP: a widget that forces its child widget to a fixed size https://github.com/wesnoth/wesnoth/commit/8a0af227194d6459a447001b0abb94f7ea220d21
20161103 19:16:32< irker865> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox 74c9e8cff54a / / (8 files in 3 dirs): Minor fixes https://github.com/wesnoth/wesnoth/commit/74c9e8cff54a2c106bce6734b1931f347b6f0277
20161103 19:16:34< irker865> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox 4ae6f51938ad / data/gui/ (macros/_initial.cfg schema.cfg widget/size_lock_default.cfg): The WML part https://github.com/wesnoth/wesnoth/commit/4ae6f51938ad254329505178dc4bd8b740ace6e3
20161103 19:16:36< irker865> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox 9a87d394bbd1 / src/gui/widgets/size_lock.cpp: Fix crashes https://github.com/wesnoth/wesnoth/commit/9a87d394bbd158c0dfadafa07589e90822099bd6
20161103 19:16:38< irker865> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox 5d955b474616 / data/gui/ (macros/_initial.cfg widget/size_lock_default.cfg): Fix the wrapped widget not filling allocated size https://github.com/wesnoth/wesnoth/commit/5d955b474616fed161bb974f3c20330764d8aa6b
20161103 19:16:40< irker865> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox a0f51669442a / src/gui/widgets/size_lock.cpp: Allow either dimension to be zero https://github.com/wesnoth/wesnoth/commit/a0f51669442afc5df02ee2c32718908f49a1d046
20161103 19:17:14< vultraz> JyrkiVesterinen: I see my fix worked as expected, then?
20161103 19:17:31< vultraz> ah :D
20161103 19:17:38< JyrkiVesterinen> I needed to apply it to another file as well, but yes, it worked.
20161103 19:17:41< celticminstrel> By the way, I agree with others on not merging this before 1.13.6...
20161103 19:18:04< celticminstrel> Even if its ultimate goal is to fix a bug, it's still a fairly big change.
20161103 19:18:42< vultraz> JyrkiVesterinen: fwiw i don't think the grow_factors were needed but no difference either way
20161103 19:19:27< JyrkiVesterinen> I figured I can just as well add them when I'm relying on automatic growth.
20161103 19:22:13< vultraz> So, quick GUI2 lesson for future reference: widgets always take their best size unless *_grow = true is specified, in which they then fill to take all available space. If one does not want that, one can use *_alignment to position the widgets otherwise. Grow factors only come into play when *_grow is used, in which case it controls how multiple cells grow in relation to each other
20161103 19:22:50-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 19:23:36< JyrkiVesterinen> I had already found that out, with the exception of *_alignment.
20161103 19:24:14< JyrkiVesterinen> (I prefer to find things out on my own, by reading either documentation or code. That way I get a lot of useful details that the above kind of quick summaries omit.)
20161103 19:24:16< celticminstrel> Grow factors probably default to either 1 or 0, right?
20161103 19:24:23< vultraz> Mordante really did come up with a quite elegant and simple design, despite its flaws.
20161103 19:24:25< celticminstrel> More likely 1 I guess
20161103 19:24:34< vultraz> celticminstrel: 1, i'd think
20161103 19:25:03< JyrkiVesterinen> I was quite surprised to find that GUI2 doesn't care about minimum sizes of widgets. It only ever queries the preferred size, i.e. best size.
20161103 19:25:07< vultraz> JyrkiVesterinen: I intend to write a wiki page on the GUI2 layout system... eventually :P
20161103 19:25:15< celticminstrel> Well, the grid implementation isn't that great.
20161103 19:25:20< JyrkiVesterinen> There is already a wiki page.
20161103 19:25:42< vultraz> yes, but I had intended to write all about using stuff like grow_factor to its fullest 
20161103 19:25:46< celticminstrel> I wish you could do away with the [row] and [column] elements and just have a series of widgets directly in the [grid].
20161103 19:25:47< vultraz> grow_factor is rather overlooked at times
20161103 19:25:47< JyrkiVesterinen> https://wiki.wesnoth.org/GUILayout
20161103 19:25:47-!- travis-ci [~travis-ci@ec2-54-198-117-233.compute-1.amazonaws.com] has joined #wesnoth-dev
20161103 19:25:48< travis-ci> wesnoth/wesnoth#11841 (master - b7ee27c : Celtic Minstrel): The build has errored.
20161103 19:25:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173045400
20161103 19:25:49-!- travis-ci [~travis-ci@ec2-54-198-117-233.compute-1.amazonaws.com] has left #wesnoth-dev []
20161103 19:25:56< celticminstrel> But some things are certainly pretty good.
20161103 19:26:26< vultraz> JyrkiVesterinen: much improvement, that page could get
20161103 19:26:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161103 19:26:43< celticminstrel> Looks like a random test failure... most of the builds passed.
20161103 19:26:49< vultraz> JyrkiVesterinen: also, widgets *can* have minimum size
20161103 19:26:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161103 19:27:11< JyrkiVesterinen> I know, but the grid implementation never queries it.
20161103 19:27:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161103 19:27:25< vultraz> Interesting
20161103 19:27:29< vultraz> considering it is considered
20161103 19:27:36< celticminstrel> vultraz: Just don't go saying that you should never use larger values than 1 for the grow factor.
20161103 19:27:54< vultraz> celticminstrel: you shouldn't, actually :)
20161103 19:28:08< vultraz> unless there are *very special circumstances*
20161103 19:28:10< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/master/src/gui/widgets/grid.cpp#L465-L478
20161103 19:28:43< celticminstrel> vultraz: I strongly disagree.
20161103 19:28:51< celticminstrel> If that were the case, why is it not a boolean flag?
20161103 19:28:52< vultraz> celticminstrel: 99% of the time one does not need different grow factors
20161103 19:29:09-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161103 19:29:22< vultraz> celticminstrel: in fact, the author of dialogs such as the old inspector implementation and the chat log used ridiculous arbitrary grow factors 
20161103 19:29:30< vultraz> and this causes subtle layout issues
20161103 19:29:34< celticminstrel> If you want one cell to take up two-thirds of the space and the other cell to take up one-third (assuming only two cells here), give them grow factors of 2 and 1 respectively.
20161103 19:30:01< celticminstrel> Ridiculous arbitrary grow factors should be avoided, yes,
20161103 19:30:20< vultraz> I have yet to find myself in a situation where one might need 2
20161103 19:30:23< celticminstrel> But there's no reason to avoid small ones, and if it causes subtle layout issues, that should be fixed.
20161103 19:30:31< celticminstrel> Uhh. I just explained such a situation?
20161103 19:30:39< vultraz> [06:30:20]	vultraz	I have yet to find myself
20161103 19:30:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161103 19:30:41< celticminstrel> Admittedly not a concrete example, but.
20161103 19:31:02< vultraz> certainly that is a valid example
20161103 19:31:10< vultraz> and i suppose i should maybe utilize that at some point
20161103 19:31:14< celticminstrel> I seem to recall needing a larger grow factor in the lobby, though you thought otherwise and reverted it.
20161103 19:31:24< vultraz> but *normally* one does not need it
20161103 19:31:26< vultraz> yes
20161103 19:31:27< vultraz> I reverted it
20161103 19:31:31< vultraz> because it was not needed
20161103 19:31:52< celticminstrel> I think your assertion that it's normally not needed is not very reasonable.
20161103 19:32:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161103 19:32:21< celticminstrel> And as a result the filter field is too small.
20161103 19:32:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161103 19:32:34< celticminstrel> Or something. I can't remember the details.
20161103 19:32:44< celticminstrel> Maybe you did find an alternate way of getting a similar effect.
20161103 19:32:47< vultraz> It looks ugly as sin in the normal resolution with the filter growing
20161103 19:32:56< vultraz> it takes up half the screen :|
20161103 19:33:07< celticminstrel> I think it's good for the filter field to be as long as possible.
20161103 19:33:17< vultraz> I disagree
20161103 19:33:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161103 19:33:40< vultraz> I also feel I'm slightly more qualified to say what is and what is not necessary in gui2 :|
20161103 19:33:48< vultraz> I've worked with it much more than you have
20161103 19:34:23< zookeeper> vultraz, ha, no can do. the dwarvish castles are cut in a weird way so can't do the same trick with them.
20161103 19:35:02< vultraz> zookeeper: D: sadness!
20161103 19:35:58< vultraz> celticminstrel: a grow factor of 2 is acceptable in the case of pairing it with a grow factor of 1. but don't use 2 and 0, or just throw in weird values like 3, 5, and 7
20161103 19:36:12< vultraz> doing so can cause very subtle layout shifts if you happen to call invalidate_layout
20161103 19:38:34< celticminstrel> I'm a little dubious about your qualifications, but whatever.
20161103 19:38:53< celticminstrel> Half the screen doesn't seem too bad to me, but maybe on really large resolutions it could be a bit much.
20161103 19:39:03< celticminstrel> Still, it should be allowed to expand a lot IMO.
20161103 19:39:19< celticminstrel> I'm not sure what 2 with 0 would even mean.
20161103 19:39:30< celticminstrel> 0 means "take whatever space is left", right?
20161103 19:39:46< celticminstrel> And if multiple specify 0, the remaining space is divided between them.
20161103 19:40:02< celticminstrel> But...
20161103 19:40:05< JyrkiVesterinen> 0 means "take no additional space at all", i.e. "never grow".
20161103 19:40:06-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 19:40:13< celticminstrel> How does it calculate how much space is left?
20161103 19:40:14< JyrkiVesterinen> 2 with 0 is the same as 1 with 0.
20161103 19:40:27< celticminstrel> (This actually also applies to using 1 and 0 together though.)
20161103 19:40:32< celticminstrel> Ah, okay.
20161103 19:41:01< celticminstrel> So in that case, yeah, there's no reason to use a 2 unless there are at least two non-zero grow factors in the row/column.
20161103 19:41:13< JyrkiVesterinen> The grid calculates remaining space with a subtraction. It takes its own height and subtracts the preferred height of every child widget.
20161103 19:41:18< celticminstrel> Though that does mean it's okay to use 2 with 0, as long as there's also a 1 or something.
20161103 19:41:52< celticminstrel> So then it distributes that space amongst the children with grow factors?
20161103 19:41:52< vultraz> My point is to look at your code and see if you can simplify it down to 0 and 1
20161103 19:41:58-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161103 19:42:09< vultraz> either using placement or grow and alignment
20161103 19:42:26-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 252 seconds]
20161103 19:42:29< celticminstrel> Placement?
20161103 19:42:35< JyrkiVesterinen> Yes, exactly. For example, if child A has grow factor 3 and child B has grow factor 1, A gets 75 % of surplus space and B gets the rest.
20161103 19:42:39< vultraz> er, ignore the placement
20161103 19:43:25< celticminstrel> The other mildly annoying shortcoming of the grid implementation is the lack of "colspan" and "rowspan", leading to requiring multiple nested grids to get the desired layout.
20161103 19:43:54< celticminstrel> What attributes do [row] and [column] accept again...
20161103 19:44:00< vultraz> I suppose i might be neglecting some useful layout subtleties with grow_factor > 1
20161103 19:44:12< vultraz> ie, not making use of them
20161103 19:44:23< vultraz> I shall have to keep this in mind \
20161103 19:44:32< vultraz> but still, I've so far managed fine
20161103 19:44:35-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 19:44:53< vultraz> might want to do some small tweaks to grow factors in the addons manager...
20161103 19:45:04-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161103 19:45:13< vultraz> or mp create, maybe?
20161103 19:45:20< vultraz> I'll look into it
20161103 19:45:36-!- mjs-de [~mjs-de@x4db5b890.dyn.telefonica.de] has joined #wesnoth-dev
20161103 19:46:03< vultraz> anyway, I don't think one should never use ones > 1, but should try to simplify their use whenever possible and not use random large numbers.
20161103 19:46:27< celticminstrel> Well, I can agree with not randomly using huge numbers.
20161103 19:47:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161103 19:47:26< celticminstrel> I guess my scons build is good enough now for working on the mass rename of GUI2 classes.
20161103 19:47:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 19:47:59< celticminstrel> I just need to be able to verify a successful build.
20161103 19:48:29-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161103 19:54:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161103 19:55:40< irker865> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox faf7f6bceffe / data/gui/window/ (lobby_main.cfg mp_join_game.cfg mp_staging.cfg): Lock sizes of most chat boxes https://github.com/wesnoth/wesnoth/commit/faf7f6bceffeeb3542eaa174a51c693336007f6b
20161103 19:56:03-!- JyrkiVesterinen_ [~JyrkiVest@78-27-98-26.bb.dnainternet.fi] has joined #wesnoth-dev
20161103 19:57:35-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 19:58:52-!- JyrkiVesterinen [~JyrkiVest@78-27-98-26.bb.dnainternet.fi] has quit [Ping timeout: 260 seconds]
20161103 19:58:58-!- JyrkiVesterinen_ is now known as JyrkiVesterinen
20161103 19:58:58-!- louis94 [~~louis94@91.178.242.245] has joined #wesnoth-dev
20161103 19:59:04-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 20:08:26-!- Lohengramm is now known as FinalBossDad
20161103 20:10:35< vultraz> "This commit leaves alone the chat box in the low-resolution version of MP
20161103 20:10:36< vultraz> lobby because attempting to lock its size blocks it from being shown at
20161103 20:10:38< vultraz> all, likely because of its width being specified as zero."
20161103 20:10:41< vultraz> but all the other cases also use 0 :|
20161103 20:11:22< JyrkiVesterinen> I guess that the containing grid doesn't have any other rows.
20161103 20:11:48< JyrkiVesterinen> In other cases, the other rows of the containing grid give the grid a non-zero width, but apparently not there.
20161103 20:12:13< JyrkiVesterinen> It is quite bad because I can reproduce the chat box size problem in 800x600 lobby as well.
20161103 20:12:31< JyrkiVesterinen> At least my branch is now an improvement. I'm writing a pull request message as we speak.
20161103 20:13:04< vultraz> JyrkiVesterinen: see what happens when you replace 0 with "(width)"
20161103 20:13:19< celticminstrel> So this is to be merged after 1.13.6 right?
20161103 20:13:22< JyrkiVesterinen> Will do after I have opened the PR.
20161103 20:13:28-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20161103 20:13:30< vultraz> celticminstrel: I shall see
20161103 20:13:35< celticminstrel> :|
20161103 20:13:35< JyrkiVesterinen> I am not going to merge it before 1.13.6, at least.
20161103 20:14:40-!- Nikitaw99 [2e004800@gateway/web/freenode/ip.46.0.72.0] has quit [Quit: Page closed]
20161103 20:15:06< celticminstrel> Does anyone have an alternate name for the display::tblit class?
20161103 20:15:18< vultraz> ...what?
20161103 20:15:21< vultraz> what is that 
20161103 20:15:59< celticminstrel> I'm not even quite sure what it's for, and calling it "blit" seems like a bad idea (because it's a verb(.
20161103 20:16:01< celticminstrel> ^)
20161103 20:16:53< vultraz> the_blit_class :P
20161103 20:17:41< celticminstrel> I'm not sure what it is, some sort of helper class.
20161103 20:17:51< celticminstrel> The comment says "Helper structure for rendering the terrains"
20161103 20:18:09< celticminstrel> Seems to wrap a list of surfaces...
20161103 20:18:51< JyrkiVesterinen> Pull request #859 opened.
20161103 20:20:09< celticminstrel> Huh? There's still use of BOOST_FOREACH in display.cpp?
20161103 20:20:50< vultraz> wha?
20161103 20:20:54< vultraz> purge it!
20161103 20:20:55< vultraz> purge it!
20161103 20:22:05< vultraz> wait what
20161103 20:22:13< vultraz> celticminstrel: actually i only see it in server.cpp
20161103 20:22:37< celticminstrel> Of course.
20161103 20:22:42< vultraz> in commented out code
20161103 20:24:12< JyrkiVesterinen> Replacing 0 with "(width)" doesn't help.
20161103 20:24:17< vultraz> damn
20161103 20:24:27< JyrkiVesterinen> The log reveals that the size_lock doesn't give enough vertical space.
20161103 20:24:37< celticminstrel> Formulas are only allowed in definitions IIRC.
20161103 20:24:44< JyrkiVesterinen> 20161103 22:23:25 error gui/layout: tgrid [_content_grid] gui2::tgrid::place: Failed to place a grid, we have 800,120 space but we need 435,469 space. This happened at a grid with the id '_content_grid' in a 'class gui2::tsize_lock' with the id '' in a 'class gui2::tgrid' with the id '_window_content_grid' in a 'class gui2::tgrid' with the id '_content_grid' in a 'class gui2::tscrollbar_panel' with the id '' in a 'class gu
20161103 20:24:44< JyrkiVesterinen> i2::tgrid' with the id '' in a 'class gui2::twindow' with the id 'lobby_main'.
20161103 20:24:46< celticminstrel> ie, they can't be used anywhere in a [window] tag.
20161103 20:25:09< vultraz> celticminstrel: the hell you talking about
20161103 20:25:13< JyrkiVesterinen> I can try to play around with the formula a bit.
20161103 20:25:15< vultraz> we use formulas all the time
20161103 20:25:38< celticminstrel> Oh.
20161103 20:25:55< celticminstrel> I'm probably getting confused with something else then.
20161103 20:26:57< Aginor> tblit is just another of our delphi style names
20161103 20:27:33< vultraz> JyrkiVesterinen: ok, i agree with gfgtdf that you don't really need a generator object
20161103 20:28:01< celticminstrel> I suppose I can leave that one if there's no good alternative.
20161103 20:28:20-!- mjs-de [~mjs-de@x4db5b890.dyn.telefonica.de] has quit [Remote host closed the connection]
20161103 20:28:25< JyrkiVesterinen> Well, I guess I was just doing cargo cult programming here. I'm not very familiar with GUI2 internals, and I used stacked_widget as a reference.
20161103 20:29:18< JyrkiVesterinen> And it turns out that the chat box does appear (even if I set width to 0) if I join the official 1.13 server.
20161103 20:29:22< celticminstrel> This seems like something that doesn't need a generator, yeah.
20161103 20:29:29< celticminstrel> Since there's only one element.
20161103 20:29:42< celticminstrel> Generators are for when there's an unknown number of child widgets.
20161103 20:30:07< JyrkiVesterinen> In other words, the problem with the 800x600 chat box is that either the player list or chat box *initially* wants to be larger than available height.
20161103 20:30:47< JyrkiVesterinen> This wouldn't be a problem if GUI2 retried layout with minimum sizes after failing to place children with preferred sizes.
20161103 20:31:04-!- travis-ci [~travis-ci@ec2-54-92-195-177.compute-1.amazonaws.com] has joined #wesnoth-dev
20161103 20:31:05< travis-ci> wesnoth/wesnoth#11843 (fixed-size-chatbox - faf7f6b : Jyrki Vesterinen): The build was broken.
20161103 20:31:05< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173063207
20161103 20:31:05-!- travis-ci [~travis-ci@ec2-54-92-195-177.compute-1.amazonaws.com] has left #wesnoth-dev []
20161103 20:31:10< JyrkiVesterinen> The exact shortcoming I pointed out an hour ago.
20161103 20:31:22< vultraz> Ok, this can wait until post-release
20161103 20:31:49< celticminstrel> JyrkiVesterinen: I seem to recall a TODO note in the source related to something similar.
20161103 20:31:59< celticminstrel> (I don't think it was quite the same thing though.)
20161103 20:32:06-!- louis94 [~~louis94@91.178.242.245] has quit [Ping timeout: 244 seconds]
20161103 20:32:08< celticminstrel> (Something in scrollbar_container maybe.)
20161103 20:32:36< celticminstrel> The 800x600 MP Create kinda looks bad still.
20161103 20:32:41< celticminstrel> I wonder what we can do about this.
20161103 20:32:48< celticminstrel> (Not going to try anything right now though.)
20161103 20:33:07< JyrkiVesterinen> (To explain in more detail: it's not a problem if a widget initially fits in allocated space and then wants to grow larger. If re-layout fails, the widget will simply remain in the place where it was originally placed.)
20161103 20:33:09< vultraz> all low-res mp create looks bad
20161103 20:33:10< celticminstrel> I think there was one label that takes up a lot of space and could probably be removed, or at least made smaller...
20161103 20:33:35< JyrkiVesterinen> (But if a widget does not fit in the allocated space initially, then it won't be placed anywhere.)
20161103 20:33:47< celticminstrel> It used to assert in that case.
20161103 20:33:50-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161103 20:33:52< vultraz> JyrkiVesterinen: perhaps you can add such a retry?
20161103 20:34:17< JyrkiVesterinen> Yes, I plan to do that. I don't tend to ignore problems I find.
20161103 20:35:01< celticminstrel> vultraz: Ah, I see the problem. Somehow I was looking at the 1.12 version of display.cpp. I have no idea how that happened...
20161103 20:37:08< vultraz> JyrkiVesterinen: i don't see any other obvious issues with the code, except the non-standard indentation in the header
20161103 20:40:06< celticminstrel> Were there two ttext classes, or just ttext_ and ttext?
20161103 20:41:13< vultraz> ttext (the pango stuff) ttext_ (gui2 widget helper) and ttext (part of the canvas code)
20161103 20:41:21< celticminstrel> Argh.
20161103 20:41:34< celticminstrel> What does the latter do?
20161103 20:41:58< vultraz> it draws the output of font::ttext (the former)
20161103 20:42:04< celticminstrel> (It's not a widget helper, it's an abstract widget.)
20161103 20:42:10< celticminstrel> Is it a private class then?
20161103 20:42:34< vultraz> yes
20161103 20:42:43< vultraz> not even in the header
20161103 20:42:55< celticminstrel> I guess I'll just rename it the same as the other ttext then.
20161103 20:44:10< celticminstrel> There's still src/lexical_cast.hpp?
20161103 20:44:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 20:44:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161103 20:44:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 20:47:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161103 20:48:02 * celticminstrel wonders what to call tformula...
20161103 20:48:26< celticminstrel> I could call it just "formula", but then there'd be confusion with game_whatever::formula.
20161103 20:51:01< vultraz> celticminstrel: yes, because it's still used 298 times
20161103 20:51:42< vultraz> though I suppose some cases could use stio
20161103 20:51:52< vultraz> but i seem to remember there were problems..
20161103 20:52:36< vultraz> oh, wait
20161103 20:52:39< vultraz> there's more than stoi
20161103 20:52:51< celticminstrel> boost::lexical_cast
20161103 20:53:02< celticminstrel> Should be a drop-in replacement for the most part.
20161103 20:53:06< celticminstrel> Not entirely sure though.
20161103 20:53:14< vultraz> there's also stoul, stdoull, stof, stod, and stold
20161103 20:53:20< celticminstrel> Yes.
20161103 20:53:32< vultraz> I shall have to work on this post-release
20161103 20:53:37< gfgtdf> celticminstrel: boost::lexical_cast has very few specialstions and does just stream s; s << in; s >> out; in most cases
20161103 20:53:52< celticminstrel> Isn't that exactly what you want though?
20161103 20:53:59< vultraz> the problem is how to deal with lexical_cast_default
20161103 20:54:06< vultraz> since that specifies a default value..
20161103 20:54:34< gfgtdf> celticminstrel: in cases like for example string -> int one can implement it muhc more effficient by just calling strtoul intenraly
20161103 20:55:05 * zookeeper unstickied the old terrain art info sticky: https://forums.wesnoth.org/viewtopic.php?f=9&t=30393
20161103 20:55:08< vultraz> you mean stoi?
20161103 20:55:42< celticminstrel> Well sure, you could if you wanted to, but I'm not convinced that would improve efficiency very much.
20161103 20:55:58< gfgtdf> vultraz: no i meant strtoul (this cod ewas written before c++11) but strtoul  will mostlikeley work aswell.
20161103 20:56:26< vultraz> gfgtdf: ftr id prefer to use c++11 functions instead of lexical_cast when possible
20161103 20:56:38< gfgtdf> vultraz: yes we can do that
20161103 20:57:29< vultraz> i just seem to recall there was some reason i had to leave some stuff...
20161103 20:57:57< vultraz> where was my std::to_string commit..
20161103 20:58:08< gfgtdf> maybe it teh beast if we first try to replace caes with stoi, stod and then think about what do to thie leical_cast
20161103 20:58:14< Shiki> vultraz, how does this work with deprecated-utils.cfg? I moved the macro now there, but I couldn't see a message when I placed a dummy unit using that macro.
20161103 20:58:20-!- Shiki is now known as shiki|sevu
20161103 20:58:28< vultraz> shiki|sevu: we need to add a message outselves
20161103 20:58:37< vultraz> shiki|sevu: we'll deal with that later
20161103 20:58:42< vultraz> none of the macros have messages yet
20161103 20:58:53< celticminstrel> What macro?
20161103 20:59:15< shiki|sevu> DRAKE_FLYING_ANIM
20161103 20:59:18< vultraz> gfgtdf: i already did a large stoi conversion
20161103 21:00:22< vultraz> ok, i remembered to_string had problems.
20161103 21:00:24< vultraz> f497d4c919491ccc5d687a77a8fd47b8221b418c
20161103 21:00:28< vultraz> c5ac29d505a6d8e5b9845a01e43268067dfbad8a
20161103 21:00:36< vultraz> seems it had problems with floating point types..
20161103 21:01:04-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20161103 21:01:05< gfgtdf> vultraz: hmm but i still see multipel cases like https://github.com/wesnoth/wesnoth/blob/master/src/units/unit.cpp#L1758 or https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/lobby/data.cpp#L406
20161103 21:01:12< shiki|sevu> I see, maybe I have a look at it
20161103 21:01:21< vultraz> gfgtdf: yes idk why i didn't do all of them
20161103 21:01:47< gfgtdf> i wonder what this is though https://github.com/wesnoth/wesnoth/blob/master/src/gui/widgets/pane.cpp#L429
20161103 21:01:58< vultraz> ah, I see
20161103 21:02:00< vultraz> "With floating point types std::to_string may yield unexpected results as the number of significant digits in the returned string can be zero, see the example."
20161103 21:02:09< gfgtdf> ahh i see its a MAKE_ENUM
20161103 21:02:27< vultraz> ok, so does that mean we need to keep lexical_cast<std::string>...?
20161103 21:02:52< gfgtdf> vultraz: the cases i pointed though are int cases though
20161103 21:02:55< celticminstrel> I'm not sure what that means.
20161103 21:03:04< vultraz> gfgtdf: yes im referring to string cases
20161103 21:03:13< celticminstrel> You mean float cases?
20161103 21:03:40< vultraz> celticminstrel: std:;to_string apparently cannot handle floating point numbers correctly
20161103 21:04:33< gfgtdf> the confusn part about is that we ahve 2 lexical_cast implementations, one in src/util.hpp and one in src/lexical_cast.hpp
20161103 21:05:07< JyrkiVesterinen> Looking at the examples at cppreference.com, the behavior seems very reasonable to me.
20161103 21:05:08< JyrkiVesterinen> http://en.cppreference.com/w/cpp/string/basic_string/to_string
20161103 21:05:09< gfgtdf> afaik they also have differently, not sure what it was exactly maybe one acceptes "123gfdhg" to retun 123 while the other did not
20161103 21:05:18< gfgtdf> behave*
20161103 21:05:25< vultraz> wat
20161103 21:05:28< vultraz> 2 implementations??
20161103 21:05:30< vultraz> good god :|
20161103 21:05:41< vultraz> ok, we'll have to deal with this post-release 
20161103 21:06:34< JyrkiVesterinen> Scientific notation isn't commonly used. I'm not surprised that std::to_string() doesn't use scientific notation.
20161103 21:06:49-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20161103 21:07:21< JyrkiVesterinen> The examples with no significant digits are all extremely small numbers which are rarely used.
20161103 21:08:04< vultraz> eh?
20161103 21:09:26< celticminstrel> Ah, so it's something like... std::to_string(0.000000000000006) might return "0.0" or so?
20161103 21:09:50< vultraz> im guessing
20161103 21:10:03-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161103 21:10:18< JyrkiVesterinen> cppreference.com example: std::to_string(1e-9) returns "0.000000"
20161103 21:10:44< vultraz> one of the times it caused problems was when i cast a double to a string to find it in a vector
20161103 21:10:54< vultraz> in hindsight, maybe not the best coding... heh 
20161103 21:11:19< JyrkiVesterinen> That sounds really fragile. :/
20161103 21:11:44< vultraz> indeed
20161103 21:12:24< irker865> wesnoth: Ignacio R. Morelle wesnoth:master 3c5332fd05c9 / SConstruct: scons: Make compiler and Boost version requirements match INSTALL https://github.com/wesnoth/wesnoth/commit/3c5332fd05c9790d189b35de3ff3fbd1372e07a4
20161103 21:12:27< irker865> wesnoth: Ignacio R. Morelle wesnoth:master 4bc38856ce2d / SConstruct: scons: Refactor and reword Info()/Warning() message presentation https://github.com/wesnoth/wesnoth/commit/4bc38856ce2db61ef190407f94b41dfb83ad7e9d
20161103 21:12:27< vultraz> probably the wrong solution too, since I just realized those values were likely supposed to be translatable...
20161103 21:12:30< irker865> wesnoth: Ignacio R. Morelle wesnoth:master bd9fea0fd3a5 / SConstruct: scons: Drop C-isms https://github.com/wesnoth/wesnoth/commit/bd9fea0fd3a5862dec9360427abba6b9d0ae05d2
20161103 21:12:33< irker865> wesnoth: Ignacio R. Morelle wesnoth:master c28e3b633c19 / scons/cplusplus.py: scons: Exclude Clang from GCC version checks https://github.com/wesnoth/wesnoth/commit/c28e3b633c191a7cc923405aa23e09cd8243511c
20161103 21:12:33-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20161103 21:13:27-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20161103 21:13:36< vultraz> JyrkiVesterinen: relevant code: https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/preferences_dialog.cpp#L77-L80 and https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/preferences_dialog.cpp#L268-L281
20161103 21:13:44< vultraz> looking at it now... quite bad, I think :/
20161103 21:13:57< vultraz> I think I'll redo that 
20161103 21:14:21< vultraz> either using a status label with a function to return an associative value, or something else
20161103 21:14:59< vultraz> it works, but only because lexical_cast<std::string> can properly handle conversions to a from doubles and strings
20161103 21:16:13< vultraz> this is worse since accl_speeds_ is of type vector<t_string> :|
20161103 21:16:17< vultraz> what was I *thinking*
20161103 21:16:34< celticminstrel> :P
20161103 21:17:00< vultraz> damn you, March 2016 vultraz!
20161103 21:17:45< JyrkiVesterinen> It would be better to create accl_speeds_ as a vector of doubles. Then you would only need to convert from doubles to strings, but not the other way.
20161103 21:18:14< vultraz> the point of that is to provide the slider with associative values to display
20161103 21:18:15< JyrkiVesterinen> Specifically, convert them to strings just before you call set_value_labels().
20161103 21:18:23< vultraz> hmm
20161103 21:18:35< vultraz> how would one do such a thing?
20161103 21:18:37< celticminstrel> And you should probably use an imbued stringstream...
20161103 21:18:49< celticminstrel> So that eg French users see "0,5" instead of "0.5".
20161103 21:19:10< vultraz> celticminstrel: pretty sure i need to mark the values as translatable
20161103 21:19:24< celticminstrel> Or add a helper function to gettext.hpp I guess.
20161103 21:19:38< celticminstrel> vultraz: If they're just numbers, it's kinda silly for them to be translatable IMO.
20161103 21:20:03< celticminstrel> You should imbue the locale into the stringstream so that it converts it properly.
20161103 21:20:09< vultraz> not every language uses arabic numerals :/
20161103 21:20:16< celticminstrel> Which does mean not using lexical_cast or to_string.
20161103 21:20:22< celticminstrel> What has that got to do with anything?
20161103 21:20:45< gfgtdf> vultraz: i dont think the other numbrs (attack diaply, hp etc.) are translatable eigher.
20161103 21:20:53< vultraz> hm
20161103 21:21:46< celticminstrel> gfgtdf: Maybe they should be localized though.
20161103 21:21:52< vultraz> JyrkiVesterinen: does vector have a copy constructor that would implicitly convert values from one vector to the type of another if they're convertible?
20161103 21:22:15< celticminstrel> The iterator constructor might work?
20161103 21:22:16< celticminstrel> Not sure.
20161103 21:22:46< vultraz> or perhaps I want std::transform
20161103 21:23:15< celticminstrel> You want that if the conversion requires a function all, certainly.
20161103 21:23:24< vultraz> but that would still mean using lexical_cast<std::string>
20161103 21:23:26< celticminstrel> For implicit conversions, I think std::copy would work.
20161103 21:24:23< vultraz> how in hell does one correctly get a string from a floating point number :(
20161103 21:24:25< vultraz> stringstream?
20161103 21:25:02< celticminstrel> Stringstream.
20161103 21:25:25< celticminstrel> ostringstream sout; sout.imbue(locale); sout << n; return n.str()
20161103 21:26:06< celticminstrel> Put that in a function and stick it in gettext.hpp, and it should be able to replace most uses of std::to_string.
20161103 21:26:32 * celticminstrel is pretty sure that's the right way to use a locale on a stream; hasn't actually done it before.
20161103 21:26:38< JyrkiVesterinen> vultraz, this is how you could make accl_speeds_ a vector of doubles: https://gist.github.com/jyrkive/2633ceee7e7961575eacd8530f59c927
20161103 21:26:43-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20161103 21:28:12< vultraz> celticminstrel: imbue?
20161103 21:28:31< vultraz> celticminstrel: and why would we want to replace uses of std::to_string?
20161103 21:28:48< celticminstrel> Well, numbers displayed to the user should be localized like I mentioned earlier.
20161103 21:28:55< celticminstrel> Probably only matters for floating-point numbers, but still.
20161103 21:28:58< vultraz> JyrkiVesterinen: that's actually pretty much exactly how i imagined it
20161103 21:29:17< celticminstrel> Well, it would matter for ints if you want to get eg "1,000" and such.
20161103 21:29:27< celticminstrel> Which in the French locale should instead be "1.000".
20161103 21:29:31< celticminstrel> But we don't do that, so...
20161103 21:29:35< vultraz> celticminstrel: so, only if to_string is being used for a user-facing string?
20161103 21:29:40< celticminstrel> Yeah.
20161103 21:29:43< JyrkiVesterinen> Or "1 000" (space) in Finnish locale.
20161103 21:30:00< celticminstrel> I could be wrong about French, maybe it should be space there too. Not entirely sure.
20161103 21:30:02< vultraz> god dammit why can't everyone use commas!
20161103 21:30:09< celticminstrel> Well, French does use commas!
20161103 21:30:14< celticminstrel> "0,5"
20161103 21:30:17< vultraz> where's the ISO when you need it
20161103 21:30:18< celticminstrel> :P
20161103 21:30:30< celticminstrel> (That's one-half, of course.)
20161103 21:30:45< vultraz> the world should use one thing, and that should be whatever 'Murica uses!
20161103 21:30:48 * vultraz jests
20161103 21:31:27< celticminstrel> But you know, in a certain sense, I live in America too. And so does shadow m IIRC.
20161103 21:32:56< vultraz> There is only one 'Murica! 
20161103 21:33:22< celticminstrel> Liiies!
20161103 21:33:24< vultraz> but in all seriousness, there are certain things that would be *really* more convenient if everyone used the same of.
20161103 21:33:31< vultraz> such as plugs
20161103 21:33:39< vultraz> what side of the road to drive on
20161103 21:33:46< vultraz> commas as place value markers...
20161103 21:34:24< celticminstrel> And then C++ decided to use apostrophes instead of commas.
20161103 21:34:29< celticminstrel> While Java chose underscores instead.
20161103 21:39:54< DeFender1031> what does wesnoth.theme_items do? The wiki's description is not particularly clear
20161103 21:40:28-!- JyrkiVesterinen [~JyrkiVest@78-27-98-26.bb.dnainternet.fi] has quit [Quit: Going to bed]
20161103 21:40:30< celticminstrel> That's the hook used to add custom status effect items.
20161103 21:40:48< celticminstrel> I guess it can add things to any part of the sidebar display. Possibly the top bar as well.
20161103 21:41:03< celticminstrel> s/items/icons/
20161103 21:41:30< celticminstrel> It's not very well documented, I guess.
20161103 21:42:22-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161103 21:48:19< DeFender1031> celticminstrel, looks like wesnoth.effects is the one used to add custom effects, no?
20161103 21:48:53< DeFender1031> the rest of your description does nothing to clear it up for me... what exactly does it do?
20161103 21:52:03-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20161103 21:55:58-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 21:56:25-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 21:56:35-!- astrelyon [~astrelyon@78.134.231.82] has quit [Client Quit]
20161103 21:56:47-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 22:00:24-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20161103 22:00:55-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20161103 22:01:59< celticminstrel> DeFender1031: Yeah.
20161103 22:02:32< celticminstrel> Basically, [effect]apply_to=xyz results in a call to wesnoth.effects.xyz(the_unit).
20161103 22:02:45< celticminstrel> It's a bit more complicated than that with the descriptions support, but...
20161103 22:02:55< celticminstrel> That's the general idea.
20161103 22:03:22-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20161103 22:04:16-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 22:04:40-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 22:04:43< DeFender1031> celticminstrel, yeah, so that doesn't explain what wesnoth.theme_items does.
20161103 22:05:06-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20161103 22:05:12< celticminstrel> Oh, I thought you were asking about wesnoth.effects, not theme_items.
20161103 22:05:23< DeFender1031> nah, .effects is obvious.
20161103 22:05:27< celticminstrel> So, theme_items is a table containing a lot of functions.
20161103 22:05:58< celticminstrel> Each function generates the contents in a specific area of the sidebar.
20161103 22:06:23< celticminstrel> So, when the game needs to update the sidebar (for example, when a new unit has been selected), it goes through and calls each function in turn.
20161103 22:06:59< celticminstrel> Example usage: https://github.com/CelticMinstrel/DruidSiege/blob/master/utils/unit-status.lua
20161103 22:08:43-!- astrelyon [~astrelyon@78.134.231.82] has quit [Client Quit]
20161103 22:08:57-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 22:18:36-!- Greg-Boggs [~greg_bogg@50-196-10-153-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20161103 22:18:53-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 22:19:08-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 22:22:51-!- travis-ci [~travis-ci@ec2-54-92-195-177.compute-1.amazonaws.com] has joined #wesnoth-dev
20161103 22:22:52< travis-ci> wesnoth/wesnoth#11847 (master - c28e3b6 : Ignacio R. Morelle): The build passed.
20161103 22:22:52< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173085364
20161103 22:22:52-!- travis-ci [~travis-ci@ec2-54-92-195-177.compute-1.amazonaws.com] has left #wesnoth-dev []
20161103 22:26:59-!- astrelyon [~astrelyon@78.134.231.82] has quit [Quit: WeeChat 1.4]
20161103 22:27:17-!- astrelyon [~astrelyon@78.134.231.82] has joined #wesnoth-dev
20161103 22:32:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 22:36:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161103 22:36:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 22:45:40-!- shiki|sevu [~Shiki@141.39.226.226] has quit [Remote host closed the connection]
20161103 22:47:56-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161103 23:06:10-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20161103 23:10:49-!- Appleman1234 [~Appleman1@KD106161210098.au-net.ne.jp] has joined #wesnoth-dev
20161103 23:12:01-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161103 23:12:33-!- Shiki is now known as shiki|sevu
20161103 23:20:25< irker865> wesnoth: Charles Dang wesnoth:master 2f6dfcfe7bd7 / src/gui/dialogs/ (preferences_dialog.cpp preferences_dialog.hpp): Preferences Dialog: refactor accelerated speed handling to avoid excessive type  https://github.com/wesnoth/wesnoth/commit/2f6dfcfe7bd70842d87f5681118ab7d00f6b053e
20161103 23:22:19< vultraz> I should probably make tslider's value label stuff more intelligent 
20161103 23:23:23< vultraz> somehow integrate it with my status label helper, maybe
20161103 23:23:50< vultraz> or at least allow a function to be passed instead of just a vector of values for 1-1 association.
20161103 23:28:31< celticminstrel> vultraz: Any plans for the number localization thing I brought up?
20161103 23:28:35< vultraz> no
20161103 23:28:45< celticminstrel> No objections to me doing it then?
20161103 23:28:56< celticminstrel> Not until after this mass rename of course.
20161103 23:29:23< vultraz> sure, if you want
20161103 23:29:46< celticminstrel> I wonder if there's a stream manipulator to insert separators.
20161103 23:29:52< celticminstrel> Though no idea if we actually want that.
20161103 23:30:01< celticminstrel> ^to enable inserting separators
20161103 23:30:18< celticminstrel> Maybe we don't. It's fairly common in games to just squash big numbers together, I think.
20161103 23:30:32< celticminstrel> (Maybe in part specifically to avoid the issue of localization.)
20161103 23:40:45< Aginor> mass rename?
20161103 23:42:23< celticminstrel> Renaming all the GUI2 classes to drop the t- prefix.
20161103 23:43:00< celticminstrel> I've mentioned it quite a few times now.
20161103 23:43:08< DeFender1031> celticminstrel, and one could theoretically add new displays to the sidebar or modify the existing ones by replaceing those functions? (Still talking about theme_items.)
20161103 23:43:12< celticminstrel> It's for immediately after 1.13.6.
20161103 23:43:27< celticminstrel> (Though we could merge Jyrki's PR first if you want, vultraz.)
20161103 23:43:34< celticminstrel> (Obviously still after 1.13.6.)
20161103 23:45:38< vultraz> gahh why do people put class definitions in the implementation 
20161103 23:45:58< celticminstrel> Not sure what you mean.
20161103 23:46:07< celticminstrel> DeFender1031: I don't think you can add new theme items.
20161103 23:46:33< vultraz> celticminstrel: like this https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/tip.cpp#L68-L105
20161103 23:46:42< celticminstrel> You can modify the existing ones, and you could probably fake new ones by adding stuff at the end of an existing one.
20161103 23:47:07< shadowm> Because it's not public.
20161103 23:47:58< DeFender1031> celticminstrel, fair enough.
20161103 23:48:05< vultraz> shadowm: fair enough
20161103 23:48:12< shadowm> <vultraz> gahh why do people not expose all implementation details
20161103 23:48:37< celticminstrel> Oh you're asking why classes are sometimes defined in source files? What shadowm said.
20161103 23:48:47< celticminstrel> ^declared in source files
20161103 23:50:30< DeFender1031> classes (or functions, or variables, or whatever) which are not supposed to be used outside a specific source file are sometimes localized to that file and can be put in an anonymous namespace to ensure nothing outside that file can use them
20161103 23:51:14 * celticminstrel still dislikes static namespaces, but I guess that's the only option for file-local classes...
20161103 23:51:20< celticminstrel> s/static/anonymous/
20161103 23:52:32< DeFender1031> celticminstrel, why do you dislike them?
20161103 23:52:55< celticminstrel> Maybe because they imply an extra level of indentation?
20161103 23:54:11< DeFender1031> indentation wouldn't be such an issue if the convention was two spaces rather than a whole tab.
20161103 23:54:26< celticminstrel> But then it'd be spaces and not tabs.
20161103 23:54:31< DeFender1031> so?
20161103 23:54:41< celticminstrel> So that's automatically a no with me.
20161103 23:54:44< DeFender1031> why?
20161103 23:54:59< celticminstrel> I'm not sure if I can put my reasons into words...
20161103 23:55:37< vultraz> boooo space indentation 
20161103 23:55:45< vultraz> 2-space indentation is ugly a'f
20161103 23:55:50< celticminstrel> (Down with PEP-8!)
20161103 23:56:03-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161103 23:56:15< DeFender1031> tabs are huge and spread the code over a wider area horizontally, forcing your eyes to have to move more (unless your particular editor has a setting to change tab width) two spaces is more than enough to easily distinguish a new indentation level.
20161103 23:56:19-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161103 23:56:28< celticminstrel> My tab with is 4 spaces.
20161103 23:56:32< celticminstrel> ^width
20161103 23:56:33< DeFender1031> vultraz, ugly how?
20161103 23:56:41< celticminstrel> The browser seems to use 8 spaces which is indeed overly huge.
20161103 23:57:01< vultraz> DeFender1031: it just doesn't look as neat to me
20161103 23:57:05< vultraz> too cramped
20161103 23:57:05< DeFender1031> (though I do seem to be outnumbered here)
20161103 23:57:28< vultraz> and also, screw pressing a key twice to indent once :|
20161103 23:57:32< celticminstrel> Actually I've used spaces for indentation before - in an XML schema, each level was indented by 1 space.
20161103 23:57:38< vultraz> that's a lot of wasted effort
20161103 23:57:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161103 23:57:53< DeFender1031> vultraz, the editor i use has a command for indenting, but I here.
20161103 23:57:55< shadowm> Editors are usually configured to insert the indentation unit when pressing Tab.
20161103 23:57:55< DeFender1031> hear*
20161103 23:57:57< celticminstrel> (Might be useful in GUI2, not that I'd really recommend it though.)
20161103 23:58:22< shadowm> Be it actual U+0009 tabs or spaces.
20161103 23:58:22< DeFender1031> celticminstrel, okay, SINGLE space indenting is a little too cramped for me :P
20161103 23:58:35< DeFender1031> shadowm, that too
20161103 23:58:44< shadowm> But I have to concur that two spaces is too little for serious programming.
20161103 23:58:54< celticminstrel> Well, I'd never use it unless it's something like an XML schema that requires very high levels of indentation.
20161103 23:59:11< celticminstrel> Even then it might be better to refactor it out to require less indentation.
20161103 23:59:24< DeFender1031> shadowm, i do serious programming all the time, and two spaces is the convention... :P
20161103 23:59:28< celticminstrel> (Usually high levels come because sub-elements are defined in-place rather than referenced from toplevel.)
20161103 23:59:38< shadowm> I struggle reading Javascript/CSS/HTML snippets using two-space indentation.
20161103 23:59:48< DeFender1031> hmm
--- Log closed Fri Nov 04 00:00:05 2016