--- Log opened Sat Oct 01 00:00:50 2016
20161001 00:15:45-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161001 00:19:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161001 00:23:37-!- irker246 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161001 00:23:37< irker246> wesnoth: Charles Dang wesnoth:master c05b8efc3fb5 / src/gui/dialogs/multiplayer/mp_staging.cpp: MP Staging: fixed bug where type id was displayed instead of name https://github.com/wesnoth/wesnoth/commit/c05b8efc3fb52103209ca1442cbb0f4e4161bdb8
20161001 00:23:38< irker246> wesnoth: Charles Dang wesnoth:master b4d460cd164c / data/gui/window/mp_join_game.cfg src/gui/dialogs/multiplayer/mp_join_game.cpp: MP Join Game: layout improvements https://github.com/wesnoth/wesnoth/commit/b4d460cd164c50fcf915ee6f2aa89d36bf3f32fa
20161001 00:23:39< irker246> wesnoth: Charles Dang wesnoth:master 722600a313dc / src/gui/dialogs/multiplayer/ (mp_staging.cpp mp_staging.hpp): MP Staging: refactored handling of settings changes https://github.com/wesnoth/wesnoth/commit/722600a313dc91ace419e36f02aee1169d483f8d
20161001 00:25:01-!- gfgtdf [~chatzilla@x4e36a2c0.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20161001 00:27:11< celticminstrel> Do I need to do a low-res version of that, by the way?
20161001 00:27:23< vultraz> Who knows
20161001 00:27:29< celticminstrel> 9_9
20161001 00:27:46< vultraz> Remember Staging was having problems displaying on low resolutions?
20161001 00:28:33< celticminstrel> Vaguely.
20161001 00:30:59< vultraz> anyway, could you look into the flg issue?
20161001 00:31:18< celticminstrel> Blargh!
20161001 00:31:20< celticminstrel> Possibly?
20161001 00:31:31 * celticminstrel did set MSVC building a minute ago...
20161001 00:36:27-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161001 00:41:59< vultraz> still a few things i need to work out with the dialogs but they're mostly done
20161001 00:42:27 * celticminstrel finds an old thread about changing the titlescreen music...
20161001 00:43:17< vultraz> that's from agggess ago
20161001 00:43:42< celticminstrel> Abou one year ago.
20161001 00:43:44< celticminstrel> ^+t
20161001 00:43:57< celticminstrel> Maybe 1.5
20161001 00:45:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161001 00:45:43< vultraz> oh hey, I forgot I've been running a wesnothd instance for a few hours
20161001 00:46:14< celticminstrel> Haha
20161001 00:48:50< vultraz> i still need to do some interface improvements to the new dialogs
20161001 00:48:52< vultraz> also
20161001 00:49:02< vultraz> but right now the major thing is the faction select
20161001 00:49:04< vultraz> dialog
20161001 00:49:05< vultraz> not showing
20161001 00:50:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 272 seconds]
20161001 00:52:32< celticminstrel> Huh, so you did end up changing the music?
20161001 00:52:52< celticminstrel> Did you change the playlist too as the thread discussed though?
20161001 00:53:09< vultraz> playlist?
20161001 00:53:18< vultraz> i ended up changing the music yes
20161001 00:53:23< vultraz> didn't touch any playlists
20161001 00:54:43-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has quit [Quit: "The highest possible stage in moral culture is when we recognize that we ought to control our thoughts." - Charles Darwin]
20161001 00:55:25-!- Jetrel [~Jetrel@2001:558:6014:1e:2422:435:dd84:bbf3] has joined #wesnoth-dev
20161001 00:57:14< celticminstrel> shadowm and others were also suggesting changing the titlescreen playlist.
20161001 00:57:28< celticminstrel> Might not be a bad idea.
20161001 00:59:27< celticminstrel> If the title theme from 1.12 is no longer so, I wonder if it'd make sense to use it in HTTT.
20161001 01:00:24< celticminstrel> Oh hey, it already is.
20161001 01:00:36< celticminstrel> As well as TRoW.
20161001 01:00:54< celticminstrel> Okay then!
20161001 01:23:38< celticminstrel> The music forum lists "scores bounced from Sibelius, Finale, etc or any other non-sampled sound libraries" as unnacceptable... so does that mean that music "bounced" from Finale using its sampled sound library is acceptable? I would assume so.
20161001 01:24:01< celticminstrel> ...I think one of the links in that post is actually directly related to Finale's sampled sound library.
20161001 01:24:26-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20161001 01:24:45< celticminstrel> ie, it's the company that produces it, I think.
20161001 01:24:53< celticminstrel> Hi.
20161001 01:28:36< tad_> Is there any desire to upgrade the Lua in Wesnoth to 5.3? I think you asked about the hyperbolic trig functions a few weeks ago. I'm thinking that was because they're no longer in 5.3?
20161001 01:28:55< vultraz> yes
20161001 01:28:56< celticminstrel> Oh yeah.
20161001 01:28:58< vultraz> we want to update to 5.3
20161001 01:29:14< celticminstrel> I remember I said I might try doing that.
20161001 01:30:22< tad_> I was thinking I'd give it a go. But I think what I'd do is rm all of it and do it as an external library. Still include but only build if the build host does not have 5.3 installed already.
20161001 01:31:05< celticminstrel> My plan was something like: 1) Dump vanilla Lua 5.2 files into the lua/ directory. 2) Commit that. 3) Revert the commit without committing, and save the diff. 4) Delete the commit. 5) Drop 5.3 Lua files into the lua/ directory. 6) Commit that. 7) Apply the patch and commit it.
20161001 01:31:16< celticminstrel> tad_: The problem with that is that Wesnoth's lualib is modified.
20161001 01:31:34< vultraz> yes
20161001 01:31:38< vultraz> shitty exception handling :|
20161001 01:31:39< celticminstrel> It might be doable nevertheless.
20161001 01:31:42< celticminstrel> Not sure.
20161001 01:31:45< celticminstrel> Oh right.
20161001 01:31:47< vultraz> tad_: what is your forum account?
20161001 01:31:55< tad_> tad_carlucci
20161001 01:31:59< celticminstrel> Probably not, since a "vanilla" lualib is probably compiled as C, which we do not want.
20161001 01:32:16-!- gfgtdf [~chatzilla@x4e363654.dyn.telefonica.de] has joined #wesnoth-dev
20161001 01:32:38< tad_> (1) what was wrong with the exception handling, and (2) what is wrong with using C linkage?
20161001 01:33:22< vultraz> tad_: this? https://forums.wesnoth.org/memberlist.php?mode=viewprofile&u=141610
20161001 01:33:39< celticminstrel> tad_: By compiling as C++ we cause Lua to use exceptions instead of setjmp.
20161001 01:33:54< tad_> vultraz: correct
20161001 01:34:02< celticminstrel> Which I think is important because Lua may call our code.
20161001 01:34:14< celticminstrel> So avoiding setjmp is a good idea to ensure destructors are always called.
20161001 01:34:24< tad_> celticminstrel: Do you want Lua to CATCH exceptions?
20161001 01:35:13< celticminstrel> Well, there's also some stuff in place to propagate exceptions through Lua code back into the Wesnoth code, but I think that's separate from what I just mentioned.
20161001 01:35:52< celticminstrel> If Lua is compiled as C, it may call setjmp, which could cause destructors in our code to not be called.
20161001 01:35:58< tad_> Cpp->Lua->Cpp(throws) should not need any fixing.
20161001 01:36:07< celticminstrel> When compiled as C++, it uses throw/catch instead for that mechanism.
20161001 01:36:19 * tad_ nods
20161001 01:36:30< tad_> That's standard in 5.3, iirc. I can check.
20161001 01:36:36< celticminstrel> (This is for Lua's own error handling mechanism.)
20161001 01:37:07< celticminstrel> I think it's standard in several versions, yes, but the key point is that to get that effect you need to compile it yourself, unless there's a separate C++ version of the lib in package repositories.
20161001 01:37:18< celticminstrel> You can't make that decision at link time.
20161001 01:39:14< tad_> OK. Your method of using a diff will discard and local changes. If there are no local changes, there is no reason to not simply replace the files (git will figure it out). But the renaming of the files bothers me.
20161001 01:40:25< celticminstrel> Huh? My method of using a diff was intended to preserve any local changes.
20161001 01:41:08< celticminstrel> I don't know why they decided to rename the files. Maybe to avoid the need to explicitly pass -xc++ on the command-line (which might've been a pain to set up in scons or CMake? I dunno).
20161001 01:41:42< celticminstrel> Some of those changes might be better placed in a separate file so that applying them is easier in later updates.
20161001 01:41:42< tad_> I'll diff it by hand but I didn't see any and I **REALLY** hope there are not other than renaming *.c to *.cpp
20161001 01:41:53< celticminstrel> There are definitely some.
20161001 01:42:20< celticminstrel> For example, luaL_argerror I think... or maybe luaL_typerror... it was removed in 5.2 but Wesnoth added it back.
20161001 01:42:44< celticminstrel> Just rename both sides to have the same extension before diffing.
20161001 01:42:59< tad_> OK. I'll start by locating any local changes. It would be better to use a local shim to the standard source and not take responsibility for the full Lua language implementation
20161001 01:43:17< celticminstrel> I really don't recommend diffing by hand (unless "by hand" means "manually running diff on each file-pair").
20161001 01:43:23< celticminstrel> "local shim"?
20161001 01:43:51< tad_> Like a file just for luaL_typerror if that's required.
20161001 01:44:31< celticminstrel> Yes, any removed deprecated functions that Wesnoth still uses should probably be in their own file. (Perhaps use that as the "user include" in lua_conf.h.)
20161001 01:44:42< tad_> I was also thinking of refactoring the Lua stuff into a Lua C++ class so we can use shared_ptr or unique_ptr to prevent leaks of the Lua state/stack
20161001 01:44:59< celticminstrel> You mean like scripting/lua_kernel_base.?pp?
20161001 01:45:10< tad_> celticminstrel: That _is_ what user include is for.
20161001 01:46:16< tad_> I mean everyplace you call lua_* or luaL_* use a C++ class and shove them into the class.
20161001 01:46:48< celticminstrel> Not entirely sure what you mean...
20161001 01:47:12< celticminstrel> I don't think there's any need to worry about the lua_State* ever leaking, though.
20161001 01:47:36< tad_> celticminstrel: Because there is only one?
20161001 01:47:39< celticminstrel> No idea if that's what you're concerned about... but I'm pretty sure lua_kernel_base takes care of that, at least.
20161001 01:47:45< celticminstrel> I dunno, is there only one?
20161001 01:47:52 * tad_ shrugs
20161001 01:47:56< celticminstrel> There could probably be two at the same time if a plugin is running...
20161001 01:48:13< celticminstrel> And I have no idea if the mapgen kernel is destroyed before the game kernel is initalized...
20161001 01:48:25< tad_> I can envision three or four at a time.
20161001 01:48:48< celticminstrel> I don't think Wesnoth has more than three potential simultaneous kernels at the moment.
20161001 01:51:44< tad_> OK. Well, the thing to do is to pull the lua files into a working directory and diff them again 5.2 to determine if there are actually any local changes, what those are, and how to isloate them.
20161001 01:52:23< celticminstrel> Yeah, that's basically what I had been thinking of doing.
20161001 01:53:37< celticminstrel> I think gfgtdf also changed the way Lua compares strings (to just use strcmp instead of a locale-friendly compare) in some (possibly misguided, I dunno) attempt to speed something up; the idea was that strings that actually need a locale-friendly compare would usually be translatable.
20161001 01:53:50< vultraz> tad_: you are now in the developers group
20161001 01:54:17< celticminstrel> I thought he was going in the Code&WML Contributors group?
20161001 01:54:21< tad_> vultraz: ty
20161001 01:54:51< vultraz> celticminstrel: that's the minimum rank
20161001 01:54:59< vultraz> I have determined he is worthy of developer rank
20161001 01:55:04 * celticminstrel shrugs.
20161001 01:55:07< celticminstrel> Whatever.
20161001 01:55:11 * tad_ shrugs too.
20161001 01:56:05< celticminstrel> Oh, by the way, vultraz - is it possible to swap controllers in the new MP staging?
20161001 01:56:25< celticminstrel> A temporary substitute for the drag-and-drop, I mean.
20161001 01:57:22< vultraz> celticminstrel: no
20161001 02:02:46 * celticminstrel wonders if vultraz's addons manager redesign addresses everything raised here https://forums.wesnoth.org/viewtopic.php?f=10&t=44008
20161001 02:06:04< tad_> Looking through old commit messages mentioning Lua we're going to want to do some refactoring, anyway. Or at least carefully check. There were some comments about having to convert double to float because Lua didn't do 64-bit floats .. if that stuff is still there it want to get gone.
20161001 02:06:46< celticminstrel> I suppose this is probably a good opportunity to do such things as well..
20161001 02:07:21< celticminstrel> You might want to take a quick look at vultraz's PR(s) for Lua 5.3 as well.
20161001 02:07:33< celticminstrel> (Possibly also any PRs for older Lua versions, if such exist.)
20161001 02:07:45< tad_> I'll check.
20161001 02:07:48< vultraz> The one I did was relatively complete except I didn't get around to re-adding exception handling
20161001 02:07:49< celticminstrel> (Though the 5.3 one is most relevant since it wasn't merged.)
20161001 02:08:33< tad_> Right now I have lua 5.2.[0-4] and am pulling the wesnoth1.13.5+dev lua sources to a scratch area so I can see what's really changed.
20161001 02:08:50< vultraz> tad_: https://github.com/wesnoth/wesnoth/pull/525
20161001 02:08:52< vultraz> was never merged
20161001 02:09:16< celticminstrel> Out of curiosity, is there a specific reason you decided you want to take this on?
20161001 02:11:15< tad_> I was looking at Lua and thinking about how it works internally and did a search for a specific question and .. Wesnoth's source tree came up. Whereupon I noted the filename changes and that it was an older version.
20161001 02:12:38< tad_> In the back of my mind has been the idea that Wesnoth is crying out for a refactoring and Lua seems as good a place to start as any other but, first, it really needs to get updated.
20161001 02:13:36< celticminstrel> I'm not sure if refactoring Lua is such a good place to start, but if you see a good way to do it, I'm not going to stop you from trying.
20161001 02:13:38< tad_> vultraz: Some of your changes are already in 5.3.4. I'll check more carefully when I've checked what we have against what was released and know how much, if any, was actually change.d
20161001 02:15:21< tad_> I'm thinking of encapsulating Lua using pImpl then looking at the uses and seeing if they can be rolled into classes which build upon that. Not sure how it's used, expect I'll learn a lot about how Wesnoth is put together.
20161001 02:15:50< celticminstrel> Not a fan of pImpl. >_>
20161001 02:16:01< tad_> Oh?
20161001 02:17:17< celticminstrel> Now I feel like I'm being expected to explain myself, but I'm not really sure how to do so.
20161001 02:18:14< tad_> I like the fact that you don't change binary compatability when you change an implementation. But that's not an issue for Wesnoth. For wesnoth, it's the compiler-firewall that will help.
20161001 02:18:53< tad_> What I don't like about pImpl is you get a lot of thunks from the public to the private.
20161001 02:18:58< celticminstrel> I suppose it could help for game_lua_kernel with its plethora of intf_* functions in the header.
20161001 02:20:01< tad_> We'll see. I've not looked that far into how Lua is married into Wesnoth. I expect I'll learn a lot.
20161001 02:20:38< celticminstrel> (Someone invented a set of prefix conventions for Lua-related functions in Wesnoth - intf_* is a regular function exposed to the API, cfun_* is a function exposed to the API as a closure, impl_* is a metafunction in the API that is not directly exposed, and luaW_* is a function related to manipulating the stack or similar, in analogy to luaL_* and lua_*.)
20161001 02:21:04 * celticminstrel isn't sure if impl_*, intf_*, and cfun_* are always used consistently though.
20161001 02:21:44< tad_> Well, it'll become appearent. One obvious test is to stub out the Lua sources and see where the linker complaints :P
20161001 02:22:37< celticminstrel> I think the vast majority of direct references to Lua (possibly all of them?) are encapsulated into the scripting/ directory.
20161001 02:23:33< tad_> When going from Lua 5.2 to 5.3, vultraz included 5.2 compatability. I can see that as a requirement, but I wonder if the mainline Lua needs it and .. if it does .. if it would not be better to upgrade the *.lua than depend upon deprecated functions
20161001 02:24:19< celticminstrel> I think it's not safe to only consider mainline here.
20161001 02:24:56< celticminstrel> You could ask zookeeper to grep the addon server for uses of things that were removed in Lua 5.3, possibly.
20161001 02:26:55< tad_> celticminstrel: Actually for UMC it would be best to use a script to check for things. Grep for atan2 sinh etc won't find much. the separation of integer from float will be the biggie, I'm thinking. Need a script for that.
20161001 02:28:07< celticminstrel> I admittedly haven't looked really closely, but I thought type() still returned "number" for both integers and floats, and I'm not sure what other relevant effects that separation could have...
20161001 02:31:56< tad_> yes, it does. But there are subtle changes. Mainly you have to watch out for a float and an integer literal in expressions.
20161001 02:32:30< wedge009> aquileia: What extra stuff needs to be built? I just built mine using your standard instructions and didn't notice anything amiss.
20161001 02:35:20< tad_> celticminstrel: The main thing is to watch out for expected results. If a float gets converted to integer you lose the fractional part. That can mean the results change .. possibly a lot .. but it really depends upon the usage. 99% of the time I'd be surprised if it makes any difference at all to UMC but I'll see if I can come up with some sort of test.
20161001 02:35:53< celticminstrel> tad_: I'd think that would only happen if explicitly requested?
20161001 02:36:10< tad_> celticminstrel: The likely trouble spots will be those UMC doing RPG-like 
20161001 02:36:11< celticminstrel> Losing the fractional part to integer conversion I mean.
20161001 02:36:28< celticminstrel> I mean, if it's a floar, I'd expect it to stay a float indefinitely.
20161001 02:36:30< celticminstrel> ^float
20161001 02:36:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161001 02:38:02< tad_> celticminstrel: Well, there's some handwaving about automatic conversions in the release notes for Lua. When the time comes I'll study them more carefully. Frankly, I'll be surprised if we have any issues or even need the compatability layer from Lua where it's not more wise to upgrade.
20161001 02:38:18< tad_> The UMC RPG is where I'd expect trouble, though, if we have any.
20161001 02:38:36< gfgtdf> celticminstrel: the main reason to change string comparistion was to  prpevent possible OOS casued by different orders on different clients.
20161001 02:38:51< celticminstrel> Oh right.
20161001 02:39:07< tad_> gfgtdf: Makes sense.
20161001 02:40:01< tad_> gfgtdf: But I wonder why we'd be comparing translatable strings anyway.
20161001 02:41:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161001 02:41:34< gfgtdf> tad_. if you want to imporve the lua exception handline code you can make it rethor all exception by default (as opposed to onyl rethrowing exceptions that inherit from lua_jailbreak_exception) this specialy means that lua doesn't catch exceptions like std::bad_alloc anymore.
20161001 02:41:56< gfgtdf> rethow*
20161001 02:43:24< tad_> gfgtdf: I think that all Lua longjmp errors can be caught and thrown as exceptions at a common point. I'll do the research. It's actualyl a common problem and I expect I can find good solutions which don't require changing the Lua released source.
20161001 02:43:30< gfgtdf> tad_: that change was about nontranslatable string.
20161001 02:44:25< celticminstrel> I think what you said is dependent on setjmp/longjmp being replaced by throw/catch, though.
20161001 02:44:54< gfgtdf> celticminstrel: yes
20161001 02:45:06< gfgtdf> celticminstrel: did anyone suggest to undo that?
20161001 02:45:11< celticminstrel> No.
20161001 02:45:30< celticminstrel> What gfgtdf was saying seems to be about propagating C++ exceptions through Lua, though.
20161001 02:45:45< celticminstrel> My basic point here is that it sounds like the two of you were thinking different things.
20161001 02:46:35< tad_> celticminstrel: Unless Lua is catching, it should not even SEE the C++ exception as the stack unwinds back to C++.
20161001 02:47:07< tad_> celticminstrel: The concern seems to be Lua throwing .. and that's fixable in a few ways.
20161001 02:47:27< celticminstrel> Pretty much, but Lua needs to be able to catch in order to avoid setjmp/longjmp. Of course, ideally it would only catch exceptions of its own internal type, though. (No idea whether it actually works that way.)
20161001 02:49:40< tad_> celticminstrel: Internally, that is, Lua catching it's own thrown errors .. it won't matter if it's exceptions or longjmp. If Lua does not need to catch C++ exceptions from called functions, then the only issue is converting the Lua longjmp into an exception so the outer C++ can catch it.
20161001 02:50:20< tad_> celticminstrel: Any there seem to be two ways in the Lua source .. compile as C++ and use exceptions .. or install a panic function and re-throw at that point.
20161001 02:50:24< celticminstrel> I think the reason it matters whether it's exceptions or longjmp is...
20161001 02:50:42< celticminstrel> Lua can call Wesnoth code which can call Lua which can call Wesnoth etc etc.
20161001 02:51:09< celticminstrel> So using longjmp may mean that destructors are not called for part of the stack.
20161001 02:51:27< tad_> Ah.
20161001 02:52:08 * celticminstrel isn't sure if there's ever more than one layer of Wesnoth sandwiched between Lua on the stack, in practice, but just one layer is enough to potentially have a problem, I think.
20161001 02:52:11< tad_> Easy enough to check that. And to check that the Lua stack goes to a sane point. OK. I'll do some tests.
20161001 02:53:22< tad_> C++->Lua->C++(throws) should unwind to the first C++ for the catch. The question is what does the Lua state* (stack) look like if it recovers and calls back into the Lua later.
20161001 02:55:32< tad_> Well, it's solvable in a number of ways. It's not unique to Wesnoth. So I should find some good guidance for it when I'm examining the issue.
20161001 02:56:09< celticminstrel> Maybe.
20161001 02:56:59< celticminstrel> I think making Lua use exceptions is honestly the simplest way though. (It's also not a local modification if I understand correctly - it seems that the Lua source automatically switches to exceptions if compiled as C++.)
20161001 02:58:33< tad_> celticminstrel: Correct on both counts. So the issue may simply be how to force C++ compilation. I'd prefer not to rename the files. Actually, I'd prefer they not even be in the repositoty. But that may be the best way given that's how it is.
20161001 02:59:21< celticminstrel> The way to force C++ compilation without renaming the files is to pass -xc++ to the compiler (for GCC/clang).
20161001 02:59:35< celticminstrel> MSVC and XCode both offer their own ways to do this as well.
20161001 02:59:53< celticminstrel> (Well, not quite sure about MSVC actually...)
20161001 03:00:00< celticminstrel> (XCode definitely does.)
20161001 03:00:17 * tad_ nods.
20161001 03:00:36< celticminstrel> Oh right, I think cl.exe has a command-line option with the same effect as -xc++, something like /Xp or something.
20161001 03:01:07< celticminstrel> If we're going to do this I should probably consider breaking out Lua into a separate target in XCode.
20161001 03:04:29< gfgtdf> what are the reasons for renaimg the lua files to .c extension?
20161001 03:04:52< tad_> celticminstrel: OK. The guidance from the Lua users group is to compile as C++. That takes care of all the esoteric stack unwinding issues. 
20161001 03:05:47< tad_> So, renaming is the simplest solution since that's what done now. 
20161001 03:06:02< tad_> I'll go with that since it's 'least change' there.
20161001 03:06:37< tad_> But I think I'll move the Wesnoth-only code into separate files so an upgrade can be more copy-and-rename and don't worry.
20161001 03:06:51< celticminstrel> In a brand-new project I'd probably go with the "force C++ at the compiler level", yeah, but in Wesnoth I'd be inclined to leave it as it is.
20161001 03:07:16< celticminstrel> If by Wesnoth-only code you mean eg luaL_typerror, then I'd be in favour of that.
20161001 03:08:12< tad_> So far, that's the only one I've found. Still slogging through it. A lot of diff's which have to do with CVS vs SVN or something like that.
20161001 03:15:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Read error: Connection reset by peer]
20161001 03:18:36-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161001 03:19:00-!- gfgtdf [~chatzilla@x4e363654.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161001 03:39:36-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161001 03:43:41-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 03:49:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161001 03:53:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161001 04:10:57-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 04:13:15< tad_> celticminstrel: The luaL_typerror is easily refactored into a wesnoth-only file is not problem. It's only used a few places.
20161001 04:13:33-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 272 seconds]
20161001 04:13:34-!- noy_ is now known as noy
20161001 04:14:10< tad_> celticminstrel: There are some minor changes to suppress compiler messages for -Wall .. (int) changed to static_cast<int>
20161001 04:14:52< tad_> celticminstrel: The work about strings for OOS is actually making sure floats all use IEEE 754 format.
20161001 04:15:48< tad_> celticminstrel: I'm out for the night. I'll look at it more tomorrow. The upgrade to 5.3.3 should not be too hard.
20161001 04:15:57-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20161001 04:21:34-!- Kwandulin [~Miranda@p200300760F2C71DDC4EB257183487241.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161001 04:24:46-!- JyrkiVesterinen [~JyrkiVest@87-100-253-33.bb.dnainternet.fi] has joined #wesnoth-dev
20161001 04:26:18-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Ping timeout: 244 seconds]
20161001 04:30:16-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161001 04:44:05-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161001 05:01:58-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 05:04:36-!- irker246 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161001 05:08:39-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161001 05:08:39-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20161001 05:36:37-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161001 05:41:40-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20161001 06:04:39-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161001 06:31:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161001 06:36:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161001 06:42:50-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161001 06:49:50< JyrkiVesterinen> vultraz: I can't reproduce the listbox issue.
20161001 06:49:59< vultraz> wha 
20161001 06:50:13< JyrkiVesterinen> I launched the add-ons manager, scrolled until LotI was visible, and clicked it.
20161001 06:50:22< JyrkiVesterinen> Clicking didn't make the list scroll.
20161001 06:50:56< vultraz> oh, right. well, that's just one of two likely-related problems.
20161001 06:51:18< vultraz> the other is in the new lobby, with a multitude of games
20161001 06:51:40< vultraz> (you can get to the 1.12 server by connecting to port 14998)
20161001 06:51:57< vultraz> it appears that every time the list is updated, it scrolls to the selected entry
20161001 06:52:06< vultraz> so the list is always jumping around
20161001 06:52:14< vultraz> which is very annoying
20161001 06:54:27< vultraz> the "root cause" in both cases would seem to be incorrect handling of listbox scroll posiiton when certain screen updates happen
20161001 06:55:56< vultraz> for the 'click to jump' issue, if one removes the functionality of tscrollbar_container::show_content_rect, it jumps all the way to the beginning
20161001 06:56:19-!- Kwandulin [~Miranda@p200300760F2C71DDC4EB257183487241.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
20161001 06:56:41< vultraz> in both cases, some code ensures the selected entry is drawn into frame
20161001 06:56:57< vultraz> it may be show_content_rect, in which case great, that function works as expected
20161001 06:57:18< vultraz> but something is still erroneously scrolling the lists to the top.
20161001 06:58:15< JyrkiVesterinen> Hmm, OK. I'll clear show_content_rect() locally and check if the list scrolls to the top in that case.
20161001 06:58:18< vultraz> I thought this had to do with the list being clear/repopulated in the lobby, but gfgtdf pointed out that the list isn't always cleared every time the timer handler is called
20161001 06:58:48< vultraz> in the addons manager, nothing is clearing the list at all
20161001 06:58:49-!- Kwandulin [~Miranda@p200300760F2C71AAC4EB257183487241.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161001 07:00:04< vultraz> I think this is likely a side-effect of scroll_labels
20161001 07:00:05< JyrkiVesterinen> The addons manager doesn't scroll to the top even if I clear show_content_rect().
20161001 07:00:14-!- aquileia [~androirc@HSI-KBW-095-208-125-086.hsi5.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20161001 07:00:26< vultraz> Try other entries besides loti
20161001 07:00:31< vultraz> ie, just run down the list :/
20161001 07:01:01< vultraz> something tells me you have a large screen
20161001 07:01:26< JyrkiVesterinen> Doesn't scroll with any entry.
20161001 07:01:36< JyrkiVesterinen> (I use a 1600x900 window.)
20161001 07:01:50< vultraz> o_o
20161001 07:02:03< vultraz> whaa
20161001 07:02:35< vultraz> ok, what about in the lobby. do you observe the games list jumping around if you scroll it to a non-top, non-selected-visible position?
20161001 07:04:10< vultraz> I was going to say I think it's likely an invalidate_layout call somewhere causes this
20161001 07:04:29< vultraz> scroll_labels (which in turn use the scrollbar_container) use it somewhere..
20161001 07:04:56< vultraz> an invalidate layout call would then pretty much erase any data of where the listbox was scrolled to before
20161001 07:05:04< vultraz> so the position would need to be restored
20161001 07:05:09< vultraz> with show_content_rect
20161001 07:05:19< vultraz> it's just a theory
20161001 07:05:27< JyrkiVesterinen> In the lobby, the list indeed scrolls to the top on its own.
20161001 07:05:42< JyrkiVesterinen> (This is with show_content_rect cleared, still.)
20161001 07:06:05< vultraz> ok, let's focus on that
20161001 07:06:20< vultraz> since that is the more pressing issue
20161001 07:06:26< aquileia> wedge009: The missing libraries were header-only, so if you copied the entire boost sources you wouldn't have any issues. Anyway, the 3 libraries have now been added to Aquileia/external, so those who don't compile boost themselves are fine as well
20161001 07:07:01-!- aquileia [~androirc@HSI-KBW-095-208-125-086.hsi5.kabel-badenwuerttemberg.de] has quit [Quit: Bye - AndroIRC]
20161001 07:08:08< JyrkiVesterinen> It also scrolls to the top if show_content_rect() is unmodified.
20161001 07:09:04< vultraz> hm
20161001 07:09:29< vultraz> maybe these are separate issues
20161001 07:10:54< JyrkiVesterinen> It may well even be intentional that the game makes the selected entry visible when the list is changed.
20161001 07:11:14< JyrkiVesterinen> That's what we want if the selected entry is already visible when the list changes.
20161001 07:12:12< JyrkiVesterinen> Maybe the game should query if the selected entry is visible before the list is changed, and skip making the entry visible afterwards if it wasn't visible before.
20161001 07:13:08< vultraz> hmm
20161001 07:13:18< vultraz> yes, it seems select_row is called..
20161001 07:13:41< vultraz> let's see what happens if i remove that
20161001 07:17:14< JyrkiVesterinen> Uh. The lobby is almost unusably slow under the debugger.
20161001 07:18:01< vultraz> hm
20161001 07:18:17< vultraz> so even without the select_row calls it still scrolls to the selected entry
20161001 07:19:35< JyrkiVesterinen> Call stack: https://gist.github.com/jyrkive/ffb667b56c6706728a3f7296d364ab43
20161001 07:20:22< vultraz> ah, indeed, content_resize_request calls invalidate_layout
20161001 07:29:44< JyrkiVesterinen> I think the easiest fix for this is for tlistbox::set_row_shown() to return early if visibility of any row hasn't changed.
20161001 07:31:09< JyrkiVesterinen> It would be nice if it didn't call content_resize_request() to merely determine if invalidate_layout() is needed, but I think avoiding the call would be hard.
20161001 07:31:53< vultraz> hm
20161001 07:32:13< vultraz> I have a feeling calling place() there could likely reset the view..
20161001 07:33:07< vultraz> I'm not exactly sure why place is called, though
20161001 07:35:06< vultraz> there's also the problem that the visibility of certain rows will change if rows are added/removed
20161001 07:39:06< JyrkiVesterinen> At least adding and removing rows is less common than calling set_row_shown() with all rows set visible.
20161001 07:40:18< vultraz> true
20161001 07:40:27< vultraz> but in the case of the lobby, it's very common :/
20161001 07:42:25< JyrkiVesterinen> I didn't see games being added or removed when a hung out in the 1.12 lobby for several minutes.
20161001 07:42:52< JyrkiVesterinen> Whereas scrolling to top uses to happen a couple of times per minute at least.
20161001 07:43:18< JyrkiVesterinen> I can at least greatly reduce the frequency of scrolling to top.
20161001 07:43:30< vultraz> games are added/removed whenever a game is started/ended
20161001 07:43:53< JyrkiVesterinen> Yes, and as I said, it doesn't seem to be that frequent.
20161001 07:43:56< vultraz> for the record, this scrolling to the top thing also affects the chat area despite best efforts :|
20161001 07:44:13< JyrkiVesterinen> Is the chat area a listbox too?
20161001 07:44:32< vultraz> a scroll label
20161001 07:44:41< vultraz> again, utilizing scrollbar_container
20161001 07:44:54< JyrkiVesterinen> (I think the chat area should have special code that scrolls to *bottom* whenever a new message appears.)
20161001 07:45:07< vultraz> there is exactly such a thing
20161001 07:45:47< JyrkiVesterinen> Oh. Then the code should probably be moved so that it runs *after* whatever scrolls to top.
20161001 07:45:55< vultraz> but
20161001 07:46:07< vultraz> if the text added wraps
20161001 07:46:10< vultraz> then it jumps to the top
20161001 07:46:30< vultraz> :/
20161001 07:46:53< JyrkiVesterinen> I actually noticed that the chatbox likes to stay at the top when I tested the activity simulation plugin.
20161001 07:47:32< JyrkiVesterinen> The plugin only adds very short messages ("asdf", "qwerty" and "zxc"), so it looks like the problem isn't exclusive to wrapping messages.
20161001 07:47:41< vultraz> :(
20161001 07:47:44-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20161001 07:47:54< vultraz> obviously there's a common thread here, somewhere
20161001 07:48:03< vultraz> I still think it's the invalidate_layout stuff
20161001 07:48:03-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20161001 07:49:38< vultraz> the problem with invalidate_layout is I think it discards any previous info and recalculates everything :/
20161001 07:49:52< vultraz> (including window size, if the dialog isn't fullscreen)
20161001 07:50:21< vultraz> so it'd make sense that stuff like scroll position is lost
20161001 07:52:13< vultraz> I'll leave you to it, since it sounds like you have some ideas
20161001 07:52:35< vultraz> If you come up with something, though, please make sure to include a detailed commit message 
20161001 07:59:54-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 264 seconds]
20161001 08:17:51-!- Ivanovic [~ivanovic@p579FBF3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161001 08:17:53-!- Ivanovic [~ivanovic@p579FBF3F.dip0.t-ipconnect.de] has quit [Changing host]
20161001 08:17:53-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20161001 08:19:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161001 08:24:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161001 08:24:53-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161001 08:25:50-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161001 08:34:23-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Read error: No route to host]
20161001 08:34:34-!- Ivanovic [~ivanovic@p579FBF3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161001 08:34:56-!- Ivanovic [~ivanovic@p579FBF3F.dip0.t-ipconnect.de] has quit [Changing host]
20161001 08:34:56-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20161001 08:55:05-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161001 09:01:05-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 272 seconds]
20161001 09:04:15-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 272 seconds]
20161001 09:04:54-!- irker954 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161001 09:04:54< irker954> wesnoth: Jyrki Vesterinen wesnoth:master 667064a8af6d / src/gui/widgets/ (generator.hpp listbox.cpp): Experimental MP lobby: scroll to selected game less often https://github.com/wesnoth/wesnoth/commit/667064a8af6d6d65d7af981edc2a7fbe4cc8ba16
20161001 09:08:35-!- mjs-de [~mjs-de@x4db60531.dyn.telefonica.de] has joined #wesnoth-dev
20161001 09:36:34< vultraz> JyrkiVesterinen: ahh thanks, this much improves the state of affairs 
20161001 09:38:49-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161001 09:39:00-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has left #wesnoth-dev []
20161001 09:49:00-!- Bonobo [~Bonobo@2001:44b8:254:3200:e0a6:5b44:12fb:1a5e] has quit [Read error: Connection reset by peer]
20161001 09:49:24-!- Bonobo [~Bonobo@2001:44b8:254:3200:e0a6:5b44:12fb:1a5e] has joined #wesnoth-dev
20161001 09:50:28< JyrkiVesterinen> All right, the problem with the chatbox is that the detection for when we are already scrolled to the end doesn't work.
20161001 09:50:29< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/667064a8af6d6d65d7af981edc2a7fbe4cc8ba16/src/gui/widgets/chatbox.cpp#L200
20161001 09:50:42< JyrkiVesterinen> If I replace that line with
20161001 09:50:45< JyrkiVesterinen> if(true || chatbox_at_end || force_scroll) {
20161001 09:51:04< JyrkiVesterinen> then the chatbox remains at the end like it should.
20161001 09:52:56< JyrkiVesterinen> It looks like append_to_chatbox() first appends the text and then tries to check if we're at the end. Merely moving the line that assigns to chatbox_at_end may be enough to fix it.
20161001 09:55:12-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161001 09:58:11-!- Appleman1234_ [~Appleman1@119.104.55.57] has joined #wesnoth-dev
20161001 10:01:15-!- Appleman1234 [~Appleman1@KD119104051022.au-net.ne.jp] has quit [Ping timeout: 272 seconds]
20161001 10:01:27< irker954> wesnoth: Jyrki Vesterinen wesnoth:master b9b0b0654ab0 / src/gui/widgets/chatbox.cpp: Fix chatbox not scrolling down when a new message arrives https://github.com/wesnoth/wesnoth/commit/b9b0b0654ab0951ce18fdedbfa7ef98aaa873ea4
20161001 10:01:30< JyrkiVesterinen> That was it. :)
20161001 10:02:49< JyrkiVesterinen> I think this is enough Wesnoth development for today. Next week I can think if the game list needs more work.
20161001 10:02:58-!- JyrkiVesterinen [~JyrkiVest@87-100-253-33.bb.dnainternet.fi] has quit [Quit: .]
20161001 10:08:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161001 10:13:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161001 10:15:11-!- Appleman1234_ is now known as Appleman1234
20161001 10:19:04-!- Kwandulin [~Miranda@p200300760F2C71AAC4EB257183487241.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161001 10:41:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161001 10:47:35-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161001 10:58:25-!- Kwandulin [~Miranda@p5DDD119F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161001 11:50:36-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161001 11:53:02-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 250 seconds]
20161001 11:56:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161001 12:01:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161001 12:08:34-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20161001 12:08:55< mordante> servus
20161001 12:17:20-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Remote host closed the connection]
20161001 12:21:16-!- Kwandulin [~Miranda@p5DDD119F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161001 12:52:41-!- Qwerty5f5f [~Qwerty@48.175.47.77.pptp.ntu-kpi.kiev.ua] has joined #wesnoth-dev
20161001 12:53:39-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161001 13:01:37-!- irker954 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161001 13:22:49-!- Kwandulin [~Miranda@p5DDD119F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161001 13:32:44-!- Bonobo [~Bonobo@2001:44b8:254:3200:e0a6:5b44:12fb:1a5e] has quit [Read error: Connection reset by peer]
20161001 13:33:04-!- Bonobo [~Bonobo@2001:44b8:254:3200:e0a6:5b44:12fb:1a5e] has joined #wesnoth-dev
20161001 13:33:25-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 272 seconds]
20161001 13:46:31-!- mjs-de [~mjs-de@x4db60531.dyn.telefonica.de] has quit [Remote host closed the connection]
20161001 13:47:12-!- Bonobo [~Bonobo@2001:44b8:254:3200:e0a6:5b44:12fb:1a5e] has quit [Quit: Leaving]
20161001 14:04:32-!- JyrkiVesterinen [~JyrkiVest@78-27-100-165.bb.dnainternet.fi] has joined #wesnoth-dev
20161001 14:51:42-!- Kwandulin [~Miranda@p5DDD119F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161001 14:53:04-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161001 15:01:51-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20161001 15:15:41-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161001 15:18:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 264 seconds]
20161001 15:18:30-!- wedge010 is now known as wedge009
20161001 15:19:04-!- Kwandulin [~Miranda@p200300760F2C71AAE1943D03B9C75FAD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161001 15:23:06-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161001 15:23:26-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161001 15:33:05-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161001 15:33:28-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161001 15:33:58-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161001 15:41:05-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20161001 15:42:24-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161001 15:50:08-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161001 15:58:06-!- irker680 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161001 15:58:06< irker680> wesnoth: Charles Dang wesnoth:master d88f591eb597 / src/ (gui/dialogs/lobby/data.cpp mp_game_settings.cpp mp_game_settings.hpp): Hack: store era addon id in mp game settings https://github.com/wesnoth/wesnoth/commit/d88f591eb59735c2e540a95a252670d6d50cac6f
20161001 15:59:07< vultraz> Oops, forgot a file
20161001 15:59:36< irker680> wesnoth: Charles Dang wesnoth:master de8a4270a4ae / src/game_initialization/create_engine.cpp: Forgot to include this in d88f591eb597 https://github.com/wesnoth/wesnoth/commit/de8a4270a4aee6cd405d5a9abf4a5034c96e451e
20161001 16:00:34-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161001 16:11:44-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161001 16:18:50-!- DeFender1031 [~DeFender1@89-138-252-80.bb.netvision.net.il] has joined #wesnoth-dev
20161001 16:25:45-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 16:30:45-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 272 seconds]
20161001 16:34:47-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161001 16:37:38-!- Duthlet [~Duthlet@dslb-146-060-179-135.146.060.pools.vodafone-ip.de] has quit [Read error: Connection reset by peer]
20161001 16:39:32-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20161001 16:43:09-!- Duthlet [~Duthlet@dslb-188-105-139-094.188.105.pools.vodafone-ip.de] has joined #wesnoth-dev
20161001 16:44:30-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20161001 16:45:30 * tad_ rolls his eyes.
20161001 16:45:59< tad_> Do you think people who program in C++ will ever learn how to program in the language?
20161001 16:46:24-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161001 16:47:51< vultraz> tad_: is this directed at someone
20161001 16:47:54< zookeeper> you mean "people" as in beyond the few oddball individuals who have somehow magically really learnt it? from what i understand, probably not... :p
20161001 16:51:59< DeFender1031> Which language? C++ is technically 4 different languages... :P
20161001 16:52:15< tad_> I'm code-reading the places luaL_typerror is actually used with an eye to refactoring where it's used.
20161001 16:55:37< tad_> People: when you have a function (say, isUnit) and you want to know it it's on the map DO NOT add a bool parameter!!! Make a function isUnitOnMap and call isUnit then check it's on the map.
20161001 16:55:57< aeth> DeFender1031: well, it's more like C++ is a language that has changed considerably over time...
20161001 16:56:17< vultraz> tad_: and what have people been doing?
20161001 16:56:30< DeFender1031> aeth, that's true too, but that's not what I'm referring to.
20161001 16:57:07< vultraz> isUnit(const bool check_on_map)?
20161001 16:57:45< tad_> I am well aware of C++'s history and agree the standards committee is mainly a bunch of fools but it's not the language at issue, it's people are not using it. Just because it looks like C and can compile C-isms does not mean you SHOULD
20161001 16:58:56< tad_> vultraz: isUnitOnMap(u) { return isUnit(u) && u->onMap }
20161001 16:59:21< vultraz> ... what is this bullshit :|
20161001 17:00:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161001 17:00:10< vultraz> that looks like a function doing more than it should
20161001 17:00:32-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 17:00:44< tad_> There's a lot of 'doing more than it should' going on.
20161001 17:00:51< vultraz> now, if the function were called is_unit_valid_and_on_map
20161001 17:00:54< vultraz> that'd be fine
20161001 17:01:18< tad_> well, the function does not exist, but should, and I'm lazy typing here ...
20161001 17:02:18< vultraz> random example of functionality overeach I've come across... 
20161001 17:02:24< tad_> But what we have is a function which may, or may not, check the map and may, or may not, return an error code and does some other stuff all the time which has little to do with any of that.
20161001 17:02:41< vultraz> the flg manager and connect engine classes have functions to generate gui1 widget contents :|
20161001 17:02:55< vultraz> instead of leaving this up to the dialog classes that used them
20161001 17:03:56< tad_> All this makes for fragile code. Lua wants to do away with luaL_typerror because it was being misused. So we put it back in because .. guess what .. we're the reason they took it out! (Well, one of them.)
20161001 17:04:28< vultraz> I vaguely remember this
20161001 17:04:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161001 17:06:29-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20161001 17:07:16< tad_> So I'm looking at WHY we need it and the reason is we have function over-reach. To fix luaL_typerror I need to fix the use and the first place I look it's a mess. So it's snowballing into refactoring part of the AI which means refactoring the Lua unit userdata which means refactoring the C++ unit which probably means somethign deeper but I'm too disgusted to look!
20161001 17:07:21< DeFender1031> "Lua wants to do away with luaL_typerror because it was being misused. So we put it back in because .. guess what .. we're the reason they took it out!" <--- HAHAHAHAHA That's the best thing I've heard all day.
20161001 17:08:23< DeFender1031> tad_, yes, refactoring tightly-coupled code into loosely-coupled code is always a nightmare.
20161001 17:08:45 * tad_ nods.
20161001 17:09:24< DeFender1031> tad_, i've done a good deal of coaxing "this logic has nothing to do with this object and shouldn't be here" code elsewhere myself.
20161001 17:09:31-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161001 17:09:37< tad_> It's gotta be done sometime. Eventually it gets to the point you can't change anything because everything is so tightly coupled you change everything to change one thing.
20161001 17:09:46< vultraz> tad_: well, good luck
20161001 17:09:47< tad_> It's gotta be done sometime. Eventually it gets to the point you can't change anything because everything is so tightly coupled you change everything to change one thing.
20161001 17:10:31< tad_> vultraz: I'll probably swallow the bile and just do what everyone else does .. whack it so it works and ignore that I'm not doing it correctly.
20161001 17:10:33< DeFender1031> Agreed.
20161001 17:10:54< vultraz> tad_: :( this is unfortunate 
20161001 17:10:55-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 17:11:04< DeFender1031> tad_, see also: https://xkcd.com/844/
20161001 17:12:01< tad_> Always an applicable xkcd
20161001 17:12:32-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161001 17:12:32-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161001 17:13:33< celticminstrel> Why did I get that message twice?
20161001 17:13:48< DeFender1031> i sometimes advocate for what I call the sabbatical approach, based on the old testament's command to stop working the fields once every seven years. "And thou shalt work the code and produce features for six release cycles, but on the seventh thou shalt let the feature development lie fallow and focus instead on cleanup"
20161001 17:14:00< DeFender1031> celticminstrel, probably because tad_ sent it twice by mistake.
20161001 17:14:13 * tad_ boggles.
20161001 17:14:23< tad_> Or he's logged in twice, as usual.
20161001 17:14:25< celticminstrel> Mind you, I have no clue what we're talking about here.
20161001 17:14:42< tad_> celticminstrel: I'm just griping about the lame code we have to deal with.
20161001 17:14:58< DeFender1031> celticminstrel, code becoming unmaintainable as feature requirements change and more is hacked on in a tightly-coupled manner.
20161001 17:15:47< celticminstrel> So Jyrki partially fixed the lobby issue?
20161001 17:15:53< vultraz> partially 
20161001 17:15:58< vultraz> and he fixed the chat
20161001 17:16:11< JyrkiVesterinen> Yes, the game list scrolls to the top less often than before.
20161001 17:16:50< celticminstrel> I'd like to make it also not scroll even if a new game is created (or a game deleted), but that's a lot harder.
20161001 17:17:17< JyrkiVesterinen> Exactly. That's why I decided to not even try it today.
20161001 17:17:29< celticminstrel> ...the generator didn't already have a way to get a bitset of visible items? o.O
20161001 17:17:53< JyrkiVesterinen> At least I didn't see one.
20161001 17:18:15-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161001 17:18:23< celticminstrel> The function you added looks identical to an existing one (but I'm not sure, it might be an existing one defined in the listbox rather than the generator).
20161001 17:19:19< celticminstrel> "get_rows_shown"
20161001 17:19:49< JyrkiVesterinen> Ah, indeed. The listbox already had such a function.
20161001 17:19:49< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/master/src/gui/widgets/listbox.cpp#L223-L230
20161001 17:20:10< JyrkiVesterinen> I'd say that the generator is a better place for that functionality, though.
20161001 17:20:28< celticminstrel> Yeah, likely so. I'd make the listbox one just forward to it then.
20161001 17:20:45-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 17:21:17< JyrkiVesterinen> OK, I'll do it.
20161001 17:23:16-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20161001 17:26:54-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Ping timeout: 264 seconds]
20161001 17:33:04< tad_> Let's see. Rather than using a conversion function for lua_unit->unit* and lua_unit->shared_ptr<unit> we have 3 functions. And then 3 more doing the same thing to check for errors before doing the wrong thing.
20161001 17:33:20< tad_> grrr
20161001 17:34:45< tad_> So if I want a unique_ptr<unit> I have to add more functions .. because we wouldn't want the compiler to optimize away all this crap, would we?
20161001 17:36:25< celticminstrel> Why a unique_ptr?
20161001 17:36:33< celticminstrel> Note that the unit_ptr is a boost::intrusive_ptr.
20161001 17:36:50< celticminstrel> And not a shared_ptr.
20161001 17:37:07< celticminstrel> (Even though it's implied to be shared in several places.)
20161001 17:37:52< irker680> wesnoth: Jyrki Vesterinen wesnoth:master 54b801a43378 / src/gui/widgets/ (generator.hpp listbox.cpp): tlistbox::get_rows_shown(): forward to tgenerator::get_items_shown() https://github.com/wesnoth/wesnoth/commit/54b801a43378604657e0e45c5262588076cb6bdb
20161001 17:39:26< tad_> celticminstrel: Just making an example. The point is that one function can do it all and the compile can figure out the conversion IF YOU DECLARE IT!
20161001 17:40:37< celticminstrel> Not quite sure what you're getting at, but maybe, I guess.
20161001 17:41:04< tad_> So we have this (bad) code smell .. 6 functions all returning the same thing, each doing it a bit differently. And why? because it's easier to copy the function than to write a conversion operator?
20161001 17:41:21-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20161001 17:42:11 * celticminstrel notes that this is mostly my fault - originally there were only two.
20161001 17:44:39< tad_> Hey, it does not matter who did it. The problem is I want to change the least-common-denominator and so I have to track down all those functions and fix each, carefully making sure I don't change something subtle like no longer ignoring the error condition and praying the calling site does not depend upon ignoring the error condition.
20161001 17:47:05-!- gfgtdf [~chatzilla@x4e36ae97.dyn.telefonica.de] has joined #wesnoth-dev
20161001 17:47:06-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161001 17:49:09< celticminstrel> Well, it's not like there are actually six functions that are almost exactly the same, though. They all ultimately forward to a single function that does most of the work.
20161001 17:52:47< tad_> And I need to change that single function. But the question is what does the change do to them .. and following the code is eye-watering. Why do we have a class which is two or three mutually-exclusive pointers, differing in type, which ultimately lead to the same underlying class?
20161001 17:54:13< celticminstrel> Not 100% sure, but it largely seems to be a question of "who owns this unit", with possible answers being "the map", "side N's recall list", "the Lua kernel", and "unknown".
20161001 17:54:40-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20161001 17:56:35< celticminstrel> I'm not really sure why that means two separate pointers are needed; ask gfgtdf.
20161001 17:57:28< tad_> Nah. The reason is sorta obvious .. it's a shim because someone used a C pointer, someone else used a boost pointer and someone ELSE used a std::shared_ptr 
20161001 17:57:41< vultraz> I tried to make the unit map use a shared_ptr
20161001 17:57:48< vultraz> drop the custom refcounting
20161001 17:58:00< vultraz> but it's beyond my abilities :|
20161001 17:58:05< celticminstrel> I don't think the custom refcounting is bad though.
20161001 17:58:10< tad_> Which is probably wise.
20161001 17:58:18< celticminstrel> What?
20161001 17:58:23< vultraz> if you can do it yourself, many kudos.
20161001 17:58:34< vultraz> it's all a mess, really :)
20161001 17:58:35< tad_> doing away with the custom ref counting is probably wise
20161001 17:58:46< celticminstrel> I'm not so sure about that.
20161001 17:59:42< tad_> celticminstrel: Think "memory leaks" and you will be
20161001 17:59:59< celticminstrel> How so?
20161001 18:00:48< vultraz> The problem I had was just touching that one little implementation detail sent me burrowing through file after file after file to correct references, and I couldn't figure out what exactly was part of the custom refcounting to remove...s
20161001 18:00:51< vultraz> so I gave up
20161001 18:01:01< tad_> vultraz: Which is where I'm at.
20161001 18:01:16< vultraz> I could give it another shot if you want
20161001 18:01:22< tad_> vultraz: No.
20161001 18:01:26< vultraz> ok
20161001 18:01:30< vultraz> (thanks :P )
20161001 18:01:42< gfgtdf> what are the disadvantages of the custom refcounting?
20161001 18:02:30< tad_> gfgtdf: None, if you're good enough to get it right. Did you, for instance, remember to lock the counter before using it? If not, you added a race condition which std:: prevented.
20161001 18:03:05< vultraz> is my (uneducated) opinion, if a standard implementation exists it it likely better than a custom implementation, since the people working on the standard version are more likely to have designed it better than you.
20161001 18:03:15< celticminstrel> No idea if boost::intrusive_ptr does that for you...
20161001 18:03:16< gfgtdf> tad_; why shodul i remember to do that? i didnt write that code
20161001 18:03:31< celticminstrel> I think it was iceiceice or something?
20161001 18:03:37< gfgtdf> tad_; and what you say it only true of thee are multiple threads accesing one unit.
20161001 18:03:41< vultraz> iceiceice is the last person to touch the intrusive_ptr crap in the unit code
20161001 18:04:02< tad_> vultraz: Finger pointing is counter-productive.
20161001 18:04:11< vultraz> I'm not finger-pointing
20161001 18:04:17< vultraz> he made it so much better than it was :P
20161001 18:04:18< gfgtdf> celticminstrel: im quite sure iceiceice wrote the unit_ptr class.
20161001 18:04:31< vultraz> (let you imagine what unit management was like before)
20161001 18:04:33< tad_> gfgtdf: And how do you prevent someone from adding a thread which accesses that same unit?
20161001 18:04:34< celticminstrel> Note that intrusive_ptr is close enough to "a standard implementation", except for the detail of intrusive_ptr_add_ref which must be implemented by your code.
20161001 18:05:02< celticminstrel> gfgtdf: unit_ptr is a typedef, not a class. :/
20161001 18:05:04< vultraz> celticminstrel: but now that the stdlib has shared_ptr it should use shared_ptr
20161001 18:05:15< vultraz> stdlib > boost
20161001 18:05:15< gfgtdf> celticminstrel: then he wrote that typedef
20161001 18:05:18< tad_> celticminstrel: That's because boost pointers became the std:: pointers with some edge conditions fixed which boost never got to.
20161001 18:05:21< celticminstrel> Note that when it was written Boost already had shared_ptr.
20161001 18:05:29< vultraz> stdlib > boost
20161001 18:05:49< celticminstrel> Sure, but intrusive_ptr is not the same as shared_ptr.
20161001 18:05:56< JyrkiVesterinen> tad_: Wesnoth is almost entirely single-threaded and not thread-safe at the moment. As a result, it is unlikely that anyone would attempt to access units from other threads.
20161001 18:06:07< vultraz> sure
20161001 18:06:15< celticminstrel> Maybe if you used enable_shared_from_this or something you could do away with intrusive_ptr.
20161001 18:06:17-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161001 18:06:18< vultraz> but the fact that we have to implement refcounting makes it bd
20161001 18:06:30< celticminstrel> (It's not like the unit class will ever have subclasses.)
20161001 18:06:34< vultraz> and makes the code messy
20161001 18:06:55< celticminstrel> I don't think it's all that messy though.
20161001 18:07:20< vultraz> src/units has 31 files
20161001 18:07:55< celticminstrel> I'm not going to say it should absolutely never be replaced with shared_ptr, mind you, but the current way works and I don't really see any reason to change it.
20161001 18:08:22< vultraz> Yes, and GUI1 "works", why not not change that too :)
20161001 18:08:23< gfgtdf> vultraz: how does having 31 files imply te refcount is messy?
20161001 18:08:36< vultraz> gfgtdf: no, the overall unit code
20161001 18:08:36< celticminstrel> Most of those 31 files are unrelated to the unit class.
20161001 18:08:57< celticminstrel> Two of them are unit types. Two are unit attacks. Six or so are unit animations.
20161001 18:09:04< vultraz> there are 31 files related in some way to the display of units
20161001 18:09:10< vultraz> display and handling*
20161001 18:09:18< vultraz> whatever that may be
20161001 18:09:41-!- Kwandulin [~Miranda@p200300760F2C71AAE1943D03B9C75FAD.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161001 18:10:07 * vultraz is gonna try to get sleep
20161001 18:10:10< tad_> vultraz: Be glad I didn't write it. I do 1 file per method and let the linker figure it all out ... so a class with 100 methods means I have 101 files ...
20161001 18:10:28< vultraz> ..............................................
20161001 18:10:49< vultraz> you're kidding, right :| you don't really put every function in its own file, do you :|
20161001 18:11:34< tad_> vultraz: If I can, yes. Sometimes I'll have a few static helpers in with it.
20161001 18:11:43< vultraz> ................ oh my god :|
20161001 18:11:44< celticminstrel> Huh. Weird.
20161001 18:12:20< vultraz> that is the worst model I could think of
20161001 18:12:25< vultraz> even worse than mvc
20161001 18:12:40< celticminstrel> Uhhh... stop right there.
20161001 18:12:54< tad_> that's apples and oranges.
20161001 18:12:55< celticminstrel> First off, it has no relation whatsoever to MVC. You cannot compare them.
20161001 18:13:07< celticminstrel> Secondly, MVC is not bad, per se.
20161001 18:13:28< vultraz> I compare them by merit of "things that make code unnecessarily complicated and/or hard to read"
20161001 18:13:41< tad_> I like a file to be small and easy to understand. I don't like having to search for a function. So if I want a method, I open the file and there it is.
20161001 18:14:59< vultraz> sounds like a nightmare for actually writing a class :|
20161001 18:15:21< tad_> Sometimes I break my rules, of course. For example, if I am using pImpl I'll put all the thunks in one file because they don't really DO anything.
20161001 18:15:29< celticminstrel> Neither automatically implies "unnecessarily complicated and/or hard to read" for me.
20161001 18:15:50< vultraz> 'oh, new function, ok, new file, add all the includes, add to build list... oh wait, i want to change this other one, open new file, switch to file browser, close old file...'
20161001 18:16:06< celticminstrel> What?
20161001 18:16:26< celticminstrel> "switch to file browser"?
20161001 18:16:27< gfgtdf> vultraz: you usuaklyl have your fileleist integrated in your ide
20161001 18:16:31< celticminstrel> "close old file"?
20161001 18:16:40< vultraz> granted
20161001 18:16:41< celticminstrel> Neither of those steps are necessary, right?
20161001 18:17:05< vultraz> i suppose i make unnecessary work for myself using n++ and windows explorer
20161001 18:17:16< tad_> Well, until recently, for me, the file browser was 'ls' and the editing window was 'vi' 
20161001 18:17:24< vultraz> D:
20161001 18:17:41< vultraz> even worse!
20161001 18:18:01 * vultraz flees
20161001 18:18:42< tad_> There's a cognitive break when you want to change that other method .. how you got to it does not eliminate the break .. Search for file .. Search for string .. you're still breaking one train of thought and taking up a new one.
20161001 18:41:44-!- gfgtdf [~chatzilla@x4e36ae97.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161001 18:41:56< tad_> s/class unit/class unitWithKitchenSink/  **sigh**
20161001 18:42:40< celticminstrel> Haha.
20161001 18:43:23< tad_> Someone needs to do a little separation of responsibility here.
20161001 18:43:35< celticminstrel> How so?
20161001 18:45:38< tad_> Well, there's stuff here for SDL .. and stuff for turns .. and stuff for scenario .. and stuff for who-knows-what .. and it if you want to know what's public, protected or private you have to CAREFULLY put your finger on the line and read upwards in the class header because it changes back and forth so often 
20161001 18:47:06< celticminstrel> That's true...
20161001 18:47:09< tad_> "I don't know where to put this." "Does it have anything to do with a unit, even tagentally?" "Yes" "unit.hpp" .. "I added it to the end and it's not compiling" "Add public: above it" .. "I added it and it's public!" "Put private: above it."
20161001 18:47:39< celticminstrel> I don't remember anything about stuff for SDL or turns or scenario, but it's probably easy to miss things in that class.
20161001 18:48:45< tad_> It's probably some sort of hook logic. Like, we need to do this to a unit on every end-of-turn, but don't want to think about it so slam it into the unit instead of designing it better.
20161001 18:49:38-!- ancestral [~ancestral@63.225.154.185] has joined #wesnoth-dev
20161001 18:50:13< tad_> You cannot compile a unit.hpp without SDL because it depends upon SDL. So no changing to Qt because we're forever married to SDL.
20161001 18:51:30< tad_> This code makes me glad I purchase Ibuprofen in the 2000-tablet sized bottle.
20161001 18:51:58-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161001 18:52:52< celticminstrel> Is that dependency something more than just eg SDL_Rect or SDL_Color or similar?
20161001 18:54:35< tad_> Who knows. The header is there. So maybe it's just some fields which should be refactored. But all of SDL is there so .. maybe? .. only way to be sure is change it and see what breaks.
20161001 18:56:02< tad_> But someone needs to separate unit-the-thing-on-the-display from unit-the-concept .. etc.
20161001 18:58:26< celticminstrel> There is a separate class for unit display, I think...
20161001 18:58:45< celticminstrel> Though it might be tightly coupled to the unit class.
20161001 18:58:59< tad_> celticminstrel: Then parts of that class are in unit.hpp and should be moved to their proper home.
20161001 18:59:49< tad_> It's all 10 years of "I don't want to think about it, I just want this one thing to work ..."
20161001 19:03:04< tad_> Consider a 'map' and a 'unit' .. the unit MAY be on the map. So there needs to be a 'map-has-units' class, probably some sort of collection, where the elements are a unit and a position. But NO, all units have a map position, it's just some don't use it. 
20161001 19:04:05< celticminstrel> There is a unit_map class which is a collection indexed by location...
20161001 19:04:31< celticminstrel> (And can also be indexed by underlying_id.)
20161001 19:04:31< shadowm> Most of that criticism about the code's design is valid and known. It'd be nice if people spent focused their efforts on improving things rather than coming up with new sardonic remarks. (This goes for vultraz too.)
20161001 19:04:42< shadowm> s/spent//
20161001 19:05:44< tad_> shadowm: The problem with technical debt is, someday, you're going to have to pay it off.
20161001 19:06:03< shadowm> Yes. And the people who introduced it are gone and we're never going to get them to do it for you.
20161001 19:06:31< shadowm> Ranting about the same issues nonstop isn't going to fix them.
20161001 19:07:03< tad_> shadowm: So the solution is to ignore them?
20161001 19:07:08< shadowm> To fix them.
20161001 19:08:35< tad_> shadowm: That's what I'm looking at. But it's snowballing. I can't fix the one issue in Lua because it changes an issue with units which changes an issue with maps, and SDL and who knows what else.
20161001 19:08:54< celticminstrel> What was the one issue in Lua, again?
20161001 19:09:11< shadowm> Perhaps you aren't used to this because you've not been here for long enough, but criticizing other people's code endlessly without providing actual solutions (moreso if those people are unable to fix their own stuff because they are either gone or don't have time to do unpaid volunteer work) only serves to create a negative atmosphere where frustration adds up and people start leaving.
20161001 19:09:41< shadowm> We already had enough of that happen over the past 4 years, and I think right now the project can't afford more of the same thing.
20161001 19:09:46< tad_> celticminstrel: At present the issue I'm looking at is the typerror function having been deprecated.
20161001 19:09:51< shadowm> Not with under a handful of active coders.
20161001 19:10:10< celticminstrel> tad_: So, are you trying to remove all uses of it?
20161001 19:10:47< celticminstrel> Or something else?
20161001 19:10:54< tad_> celticminstrel: There is a nearly equvalent function but I need to be sure all the points-to-unit point to the same sort of unit and there's 3 different types of pointer-to-unit.
20161001 19:11:17< celticminstrel> Are you talking about luaL_argerror?
20161001 19:12:12< tad_> That's where typerror ends up.
20161001 19:12:44< JyrkiVesterinen> luaL_typerror is just a wrapper aroung lua_error. It shouldn't be hard to implement equivalent functionality manually...
20161001 19:12:53 * celticminstrel assumes typerror could be trivially implemented with argerror + ostringsteam.
20161001 19:12:56< JyrkiVesterinen> We could even have a luaW_typerror if we want.
20161001 19:13:06< tad_> One solution is to move luaL_typerror to a separate file, which is fine.
20161001 19:13:16< celticminstrel> I'd prefer it to be luaW_typeerror though. :P
20161001 19:13:25< celticminstrel> It bugs me that there's only one E.
20161001 19:13:57< tad_> But there is a function checktype ??? which does the same thing as typerror but has some additional checking .. which looks like it's already done where we're using typerror now ..
20161001 19:14:02< celticminstrel> Incidentally, if we did add a luaW_typerror or whatever, we could probably make it use the __metatable field for userdatas...
20161001 19:14:05-!- vincent_c [~bip@vcheng.org] has quit [Quit: Coyote finally caught me]
20161001 19:14:11-!- ancestral [~ancestral@63.225.154.185] has quit [Ping timeout: 265 seconds]
20161001 19:14:25-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20161001 19:14:57< tad_> celticminstrel: The __metatable IS the difference between the two Lua functions .. typerror and check-whatever-I-need-to-find-it-again.
20161001 19:16:04< tad_> celticminstrel:  So the question is do all those unit pointer types point to the thing with the metatable is Lua knows about that pointer type? And that's where I'm snowballing into what's wrong with teh pointer types and why do we have three when one will do?
20161001 19:16:50< celticminstrel> I think we could probably have just one pointer along with an enum, but not sure.
20161001 19:17:09< celticminstrel> A unit_ptr probably.
20161001 19:17:14< celticminstrel> Rather than unit*
20161001 19:17:16< tad_> Have that.
20161001 19:17:20< tad_> And have that.
20161001 19:17:28< tad_> And have intrusive_ptr
20161001 19:17:34< celticminstrel> I forget, did I add an enum?
20161001 19:17:36< celticminstrel> Wait what?
20161001 19:17:37< tad_> and have sharer_ptr
20161001 19:17:40< celticminstrel> Huh?
20161001 19:17:44< celticminstrel> Wha?
20161001 19:18:48< JyrkiVesterinen> Uh, unit_ptr is intrusive_ptr.
20161001 19:18:48< JyrkiVesterinen> typedef boost::intrusive_ptr<unit> unit_ptr;
20161001 19:18:52< tad_> When I look for pointer-to-unit things I'm finding all of the std:: and boost:: and C and C++ ways to have pointers and references and references to pointers and my head is spinning
20161001 19:19:20< celticminstrel> lua_unit should probably have an anonymous union or something.
20161001 19:19:58< celticminstrel> Or it could just store a pointer and forget about recording which recall list it's on or the unit's underlying ID.
20161001 19:20:03< tad_> celticminstrel: and unit_ptr iis a class which is just a bunch of pointers which on we use depends on which is set.
20161001 19:20:27< tad_> All end up at 'class unit' eventually.
20161001 19:20:53< celticminstrel> I don't know if there's any good reason for lua_unit to not store pointers into the unit_map or recall lists.
20161001 19:21:28< celticminstrel> I think you could likely just have one unit_ptr along with an enum to distinguish who owns the unit.
20161001 19:22:29< tad_> I think the goal is it's all a std::shared_ptr<unit> at some point. But getting there .. well, I still have about 300 ibuprofen in the bottle .. should be enough.
20161001 19:23:51< tad_> I looked at boost::intrusive_ptr vs std::shared_ptr .. the difference is shard_ptr is thread-safe and supports weak pointers, but boost::intrusive is faster and has a smaller memory footprint.
20161001 19:24:53< tad_> If I could prove we ever leak a 'class unit' object it would be a good reason to switch.
20161001 19:24:59< JyrkiVesterinen> Intrusive_ptr also has the advantage that you can safely create an intrusive_ptr out of a raw pointer, without caring how many other intrusive_ptrs to the same object there are.
20161001 19:25:47< JyrkiVesterinen> For that reason switching between intrusive_ptr and shared_ptr would be a big decision.
20161001 19:26:15< tad_> JyrkiVesterinen: Which is saying if you can find the unit without using the pointer, you can do the end-run around the existing pointer.
20161001 19:26:53-!- Nobun [~nobun@host133-48-dynamic.3-87-r.retail.telecomitalia.it] has joined #wesnoth-dev
20161001 19:33:58< tad_> celticminstrel: OK. I think your solution is the 'least change' solution. Move luaL_typerror to luaW_typeerror.cpp and change the dozen references to use the new name.
20161001 19:36:28< tad_> shadowm: What I am attempting to do is refactor the wesnoth changes the www.lua.org so it's easier to drop in a new Lua. Right now most of the changes are spurious and should not be made at all. There are only 4 or 5 actual changes and if I can refactor them to our code without changing theirs future changes will be easier.
20161001 19:42:46< tad_> New subject: Lua uses strcoll and the current locale. Wesnoth changes that to stdcmp. The ONLY place Wesnoth uses stdcoll is sorting the titles for the help viewer.
20161001 19:44:01< celticminstrel> tad_, JyrkiVesterinen: There is an std::enable_shared_from_this which might help if switching from intrusive_ptr to shared_ptr (not that that's an argument to switch).
20161001 19:44:07< tad_> So .. is the Help viewer callable (directly or indirectly) from Lua? If not, then rather than change the source for Lua, changing to the "C" locale would do the same thing
20161001 19:46:36< tad_> grr s/stdcmp/strcmp/  s/stdcoll/strcoll/
20161001 19:48:01< tad_> celticminstrel: There's a lot on the subject. It comes down to whether threading is wanted, weak pointers are wanted (either: use std::) or whether you're doing so much pointer work on so many small objects the performance improvement is of intrusive_ptr is important.
20161001 19:48:07< celticminstrel> The help viewer is callable from Lua.
20161001 19:48:27< celticminstrel> Directly, even.
20161001 19:48:36< celticminstrel> Something like wesnoth.open_help_topic("blah")
20161001 19:49:06< tad_> celticminstrel: So I need to store the locale when Wesnoth starts and use "C" .. and switch to/from in the help viewer. NP.
20161001 19:49:19< celticminstrel> Changing to the "C" locale sounds fine as long as it doesn't interfere with the Boost gettext implementation.
20161001 19:50:05< celticminstrel> In the help viewer you might be able to avoid strcoll by using the t_string comparison function which I think is defined in gettext.hpp (for some bizarre reason).
20161001 19:50:39< celticminstrel> (Maybe it's not t_strings, but basically it does a locale-friendly comparison the C++ way rather than with strcoll.)
20161001 19:51:51< tad_> That is the ONLY place strcoll appears in the source. I will check gettext and look at t_string .. I have a feeling there will be point point where I can setlocale() and avoid the Lua source changes.
20161001 19:53:04< tad_> If I can, it means we could add a Preferences to allow the user to select language and locale (if we don't already) so something other than their system default.
20161001 19:53:34< celticminstrel> How is that different from the Language button at the title screen? :P
20161001 19:53:55< celticminstrel> It's possible that gfgtdf's locale-friendly comparison actually ignores the global locale.
20161001 19:54:17< tad_> we'll see.
20161001 19:54:31< celticminstrel> (And the same with the Boost gettext implementation. I'm not sure about date-time-related stuff though.)
20161001 19:55:15< celticminstrel> I'm a little curious about those spurious changes to the Lua source that you mentioned. >_>
20161001 19:56:11< tad_> Some whitespace changes. Mainly CVS comments got removed from every file. I don't remember, does git delete CVS version comments?
20161001 19:56:28< celticminstrel> I doubt it?
20161001 19:56:40< tad_> So someone did it by hand, which is silly.
20161001 19:57:53< JyrkiVesterinen> I looked earlier today at change history of the src/lua directory.
20161001 19:58:17< JyrkiVesterinen> Indeed, a significant part of the commits is wholesale changes which affected the entire repository.
20161001 19:58:28< JyrkiVesterinen> Lua should have been excluded from them.
20161001 19:59:45-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 272 seconds]
20161001 20:01:19< tad_> JyrkiVesterinen: If I can't get down to 'copy the files and you're done.' I want to get down to a brief HOWTO describing each change so future upgrades to Lua can be done quickly without having to search for what WE changed anddeciding if it was needed or spurious.
20161001 20:02:00< JyrkiVesterinen> Sounds like a very useful goal. :)
20161001 20:02:39< tad_> My real preference would be to build Lua as a separate dependancy and use a "vanila" static library for it. But that does not look to be possible.
20161001 20:05:36-!- Appleman1234 [~Appleman1@119.104.55.57] has quit [Ping timeout: 244 seconds]
20161001 20:12:12-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 20:30:56-!- JyrkiVesterinen [~JyrkiVest@78-27-100-165.bb.dnainternet.fi] has quit [Quit: .]
20161001 20:35:05-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20161001 20:35:07-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161001 20:38:49-!- irker680 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161001 21:09:04-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161001 21:21:00< tad_> celticminstrel: t_string does not support anything other than == and != which wind up being const char* operators == and != so locale does not effect the comparisons.
20161001 21:23:30< tad_> celticminstrel: It looks to me like the strcoll for the help viewer is the only place Wesnoth does NOT setlocale (using boost locale, eventually) before working with the strings.
20161001 21:25:19< tad_> celticminstrel: so the issue, as I see it is that Lua never changes the locale so it's whatever was last set, which will be "English" or "C" for a while after we fire up, then change randomly as we're running.
20161001 21:27:01< tad_> The 'correct' thing would be to have all Lua scripts setlocale before doing < or <= on strings because if we use strcmp we're wrong if it's translated but if we use strcoll we're wrong if it's not translated.
20161001 21:27:37< celticminstrel> I think part of the rationale was that you should use t_string for user-visible strings in Lua.
20161001 21:28:00< celticminstrel> And comparing those does use the locale (it compares with a function defined somewhere, not with t_string's comparison operators).
20161001 21:28:04< tad_> Still wrong if you try < or <= .. which is NOT supported everywhere outside Lua
20161001 21:28:39< celticminstrel> I think that function is defined in gettext.hpp (which is a weird place for it but whatever).
20161001 21:29:00< celticminstrel> t_string in C++ does not support less than, but the Lua t_string does.
20161001 21:29:20< tad_> I think gettext.cpp has better never be compiled because gettext_boost.cpp defines the same things ...
20161001 21:29:32< celticminstrel> Yes, gettext.cpp is not compiled.
20161001 21:29:38< tad_> Oh, good.
20161001 21:29:58< celticminstrel> Unless someone decides to build against libintl for some reason, in which case gettext_boost.cpp is not compiled.
20161001 21:30:07< celticminstrel> (No idea if that actually works.)
20161001 21:30:33< celticminstrel> But gettext.hpp is the header for both of them.
20161001 21:30:44< tad_> There is hand-waving about it and it probably will compile but I'd be very nervous about it working PROPERLY.
20161001 21:31:19< tad_> Anyway, Lua does not have 't_string' it's all 'char *'
20161001 21:31:31< celticminstrel> It's a userdata.
20161001 21:31:38< celticminstrel> t_string in Lua
20161001 21:32:10< shadowm> Why hasn't the GNU gettext-based implementation of the API been removed yet?
20161001 21:32:20< celticminstrel> I have no idea.
20161001 21:32:32 * tad_ shrugs, too.
20161001 21:32:45< tad_> It's just apparent when code-reading it's not compiled.
20161001 21:32:46< shadowm> vultraz, gfgtdf: Why hasn't the GNU gettext-based implementation of the API been removed yet?
20161001 21:32:52< celticminstrel> I was about to remove references to it from INSTALL (and scons and CMake) since neither MSVC nor XCode includes it, but then I realized the file was still there.
20161001 21:33:02< celticminstrel> Do you want me to remove it?
20161001 21:33:08< shadowm> No.
20161001 21:33:18< tad_> Move it to the attic?
20161001 21:33:18< celticminstrel> ...so why are you asking?
20161001 21:33:31< celticminstrel> I don't think the attic is intended for code.
20161001 21:33:35< shadowm> Now I'm asking the people who are either in charge of that transition or are the release manager.
20161001 21:33:45< shadowm> tad_: It is compiled if you use the right options and it was important to keep it around for 1.12.
20161001 21:33:52< celticminstrel> gfgtdf is in charge of that transition?
20161001 21:34:10< shadowm> Both for the OpenPandora builds and for older Linux distributions including what at the time was the latest Ubuntu LTS.
20161001 21:34:16< shadowm> LTS release.
20161001 21:34:35< shadowm> Yes, gfgtdf and iceiceice were heavily involved in introducing the Boost.Locale implementation for 1.11.19.
20161001 21:34:40< shadowm> As well as Boost.Filesystem.
20161001 21:35:57< shadowm> Having dropped support for OpenPandora and introduced the C++11 compiler requirements, I believe there's no excuse to keep the old implementation around anymore.
20161001 21:36:14< tad_> So, t_string goes to Lua as userdata .. which means the only way it gets to be a char* is if it's extacted .. so, if it's possible to extract userdata to char* for t_string then we're doing the wrong thing with strcmp for < and <= in those cases.
20161001 21:36:18< shadowm> But I'm asking anyway in case I missed something.
20161001 21:37:05< celticminstrel> tad_: The t_string metatable in Lua supports __tostring, so it can be converted to a normal char*. You can find the details somewhere in lua_common.cpp.
20161001 21:37:09< celticminstrel> I think near the top.
20161001 21:37:17< tad_> ok
20161001 21:39:52< tad_> So we're doing the wrong thing by t_string if we use strcmp and the wrong thing by Lua strings if we use strcoll ... the difference is with strcoll we can fix it in the Lua but with strcmp we're stuck.
20161001 21:40:08< tad_> I know .. this was probably all hashed out long ago ...
20161001 21:40:34< tad_> The choice seems to have been to use strcmp and tell anyone who does < or <= on t_strings to stop doing that.
20161001 21:42:00< tad_> So, I guess I move the change to strcmp to the wesnoth must-change column ...
20161001 21:45:13< tad_> gtg bbl
20161001 21:45:19-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20161001 21:46:10-!- gfgtdf [~chatzilla@x4e36ae97.dyn.telefonica.de] has joined #wesnoth-dev
20161001 21:46:55-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161001 22:08:25-!- Nobun [~nobun@host133-48-dynamic.3-87-r.retail.telecomitalia.it] has quit [Quit: Salve a tutti]
20161001 22:12:16-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 22:35:41< vultraz> shadowm: there is no reason I know of.
20161001 22:37:04-!- irker916 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161001 22:37:04< irker916> wesnoth: Pentarctagon wesnoth:master 5990347ed141 / data/gui/window/wml_message.cfg: Fix the content of a message getting squished https://github.com/wesnoth/wesnoth/commit/5990347ed14131a69eed3c79ac382a4d9b979703
20161001 22:37:04< irker916> wesnoth: Pentarctagon wesnoth:master 05cf2ba6cf8e / data/lua/wml/message.lua: Add ability to display two portraits at once https://github.com/wesnoth/wesnoth/commit/05cf2ba6cf8e60fe28a9d85d4a46d7743c36176c
20161001 22:37:05< irker916> wesnoth: Pentarctagon wesnoth:master 9df77488e31e / data/lua/wml/message.lua: Update message.lua https://github.com/wesnoth/wesnoth/commit/9df77488e31eb3ed8796c7353108efadba8e8494
20161001 22:37:06< irker916> wesnoth: Charles Dang wesnoth:master cb46968285d4 / data/ (gui/window/wml_message.cfg lua/wml/message.lua): Merge pull request #806 from Pentarctagon/Pentarctagon-two-portraits-fix https://github.com/wesnoth/wesnoth/commit/cb46968285d414cb7811746ba66eab9377a36f43
20161001 22:47:03-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161001 23:00:15-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 272 seconds]
20161001 23:01:17< celticminstrel> So, should I remove it?
20161001 23:02:02< celticminstrel> You probably shouldn't merge things so quickly, vultraz. Not that I have a problem with this one, but I didn't even get a chance to look at it.
20161001 23:02:27< vultraz> I looked over the code, and it seemed reasonable.
20161001 23:03:10< celticminstrel> That's not the point.
20161001 23:03:17< celticminstrel> Also, the third commit should've been squashed into the second.
20161001 23:05:48-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Write error: Broken pipe]
20161001 23:06:25< irker916> wesnoth: Charles Dang wesnoth:master 5037d8e87681 / src/gui/dialogs/lobby/data.cpp: Lobby: use mp_scenario_name for unknown scenarios https://github.com/wesnoth/wesnoth/commit/5037d8e87681242957a5613739c8c57d0a88db54
20161001 23:07:24-!- Ivanovic [~ivanovic@87.159.191.63] has joined #wesnoth-dev
20161001 23:07:43-!- Ivanovic [~ivanovic@87.159.191.63] has quit [Changing host]
20161001 23:07:43-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20161001 23:08:02-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161001 23:17:15-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20161001 23:20:42-!- Duthlet [~Duthlet@dslb-188-105-139-094.188.105.pools.vodafone-ip.de] has quit [Quit: leaving]
20161001 23:27:15 * vultraz ponders removing the Unknown Scenario/Unknown Era text
20161001 23:27:19< vultraz> it's rather misleading
20161001 23:28:58< vultraz> but what should I put in its place
20161001 23:29:14< gfgtdf> vultraz: why is it misleading?
20161001 23:29:35< vultraz> Because it actually means "you don't have this scenario/era installed"
20161001 23:30:38< celticminstrel> Replace it with the actual scenario/era name.
20161001 23:30:47< vultraz> That's already there
20161001 23:30:53< gfgtdf> vultraz: well unknown means 'unknown to this game client' here so it makese sense to me, 
20161001 23:31:03< celticminstrel> Oh, then just say "(not installed)" or something?
20161001 23:31:05< gfgtdf> vultraz: i wondewr does it show whether it available on the addon server or not
20161001 23:31:20< vultraz> no, it's not that smart :P
20161001 23:31:28< gfgtdf> vultraz: i mean it is possible that the addon is not available on the addon server
20161001 23:31:44< tad_> How did you get the name? From an installed addon or scenario?
20161001 23:31:45< gfgtdf> vultraz: and i thouigh we have a 'automaticly ownload scensrios' feature
20161001 23:32:37< tad_> If you can determine whether it is simply not-downloaded or actually not-available, maybe change the message to reflect which is the case?
20161001 23:33:04< vultraz> Essentially, it does this: installed - scenario/era name. not installed - unknown scenario/era: addon_id
20161001 23:33:15< mattsc> Hmm — is the “skip AI moves” preference wired in backwards at the moment?
20161001 23:33:39< mattsc> For me, it seems to skip the moves when the box is not checked
20161001 23:33:45< tad_> vultraz: So it is either 'not downloaded' or 'error in scenario'?
20161001 23:33:57< vultraz> (used to be "unknown scenario/era: scenario/era id", but that was ugly)
20161001 23:34:20< vultraz> tad_: it's considered unknown if it's not found in your game cache.
20161001 23:34:27< vultraz> that's essentially it.
20161001 23:34:30< gfgtdf> vultraz: maybe when connecting to he multiplayer server tha game can also ask the addon server fora  complete list of avilable addons on that server so that he knows which ones are avaiable
20161001 23:35:20< vultraz> hm
20161001 23:35:22< vultraz> that's an idea
20161001 23:35:46-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161001 23:36:04< tad_> mattsc: I concur, the checkmark does seem inverted to the effect.
20161001 23:36:41< vultraz> mattsc: the fix would be simple
20161001 23:36:43< mattsc> tad_: okay, thanks for confirming; it did not use to be that way; should be an easy fix though for whoever did this
20161001 23:36:48< mattsc> vultraz: ^  :)
20161001 23:39:53< tad_> I do not use Scon .. confirm please .. if I add a source file to ~/src/lua I need to add the file to the Sconscript there .. but if I add it elsewhere is there another such I need to change .. and what about other build systems .. do we have a checklist someplace on what to change, where?
20161001 23:41:59< vultraz> why is the preference 'skip ai moves', but the internal key is 'show_ai_moves' :|
20161001 23:42:22< tad_> Well, that explains the issue ...
20161001 23:42:52< vultraz> the issue more likely arose when i transitioned prefs to the field system
20161001 23:43:15< tad_> I'm checking 1.12.6 now.  It says 'Skip ...' and is checked.
20161001 23:43:24< vultraz> it saves the value as yes/no depending on whether it's selected or not.
20161001 23:43:45< vultraz> but the internal value is used inversely 
20161001 23:44:40< tad_> 1.12.6 the checkmark seems to align correctly with the effect.
20161001 23:46:18< vultraz> ..ok here' some weirdness..
20161001 23:46:30< vultraz> oh
20161001 23:46:31< vultraz> hm
20161001 23:47:44< vultraz> I should just fix the internal key, really
20161001 23:49:01< vultraz> or should i fix this in prefs
20161001 23:49:02< vultraz> hmm
20161001 23:49:08< vultraz> what is the right solution
20161001 23:51:05< tad_> The correct solution is to be consistent. I would not change the UI since it was 'Skip' in 1.12 so I'd suggest renaming the variable and checking proper usage everywhere.
20161001 23:52:39< celticminstrel> Personally I'd just invert it for UI purposes, but if you want to change the variable name and all uses of it, I won't stop you.
20161001 23:53:08< loonycyborg> tad_: all sources are kept in src/SConscript, with the exception of lua
20161001 23:53:13< loonycyborg> since it's third party project
20161001 23:53:42< tad_> loonycyborg: Do I need worry about similar stuff for other build systems?
20161001 23:54:00< loonycyborg> cmake works in same way
20161001 23:54:11< loonycyborg> and we expect people to update only those two generally
20161001 23:54:39< tad_> loonycyborg: OK. I'll find the cmake config and do just those two.
20161001 23:54:45< tad_> loonycyborg: ty
20161001 23:59:55-!- Qwerty5f5f [~Qwerty@48.175.47.77.pptp.ntu-kpi.kiev.ua] has quit [Quit: zzz]
--- Log closed Sun Oct 02 00:00:12 2016