--- Log opened Tue Apr 17 00:00:46 2018 20180417 00:03:26-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20180417 00:09:15-!- Kawa[m] [kawamatrix@gateway/shell/matrix.org/x-nzhtbvejhfefnhfa] has quit [Ping timeout: 256 seconds] 20180417 00:09:22-!- syrma[m] [syrmamatri@gateway/shell/matrix.org/x-hknfhdtdfpzghqpm] has quit [Ping timeout: 240 seconds] 20180417 00:09:23-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-njbmwiliymgrqobz] has quit [Ping timeout: 240 seconds] 20180417 00:10:13-!- madmax28 [madmax28ma@gateway/shell/matrix.org/x-irazictwrdhwopoh] has quit [Ping timeout: 256 seconds] 20180417 00:17:11< irker523> wesnoth/wesnoth:1.14 Jyrki Vesterinen 77b9bc3969 [heal_unit]: ensure that heal amount is AppVeyor: All builds passed 20180417 00:34:42<+discordbot> @Vultraz Any objection to me reverting the latest gettext.h commit(https://github.com/wesnoth/wesnoth/commit/275057df59ae52214761d73bc32bbb96a7595f10)? As it is, tons of warnings about the attribute being ignored are printed for just about every single file when c++17 is enabled: https://travis-ci.org/wesnoth/wesnoth/jobs/367431854#L575 20180417 00:36:05-!- travis-ci [~travis-ci@ec2-54-144-195-124.compute-1.amazonaws.com] has joined #wesnoth-dev 20180417 00:36:06< travis-ci> Pentarctagon/wesnoth#430 (travis-17 - 3bdc237 : pentarctagon): The build is still failing. 20180417 00:36:06< travis-ci> Build details : https://travis-ci.org/Pentarctagon/wesnoth/builds/367431819 20180417 00:36:06-!- travis-ci [~travis-ci@ec2-54-144-195-124.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180417 00:47:22-!- octalot [~steve@178.165.130.119.wireless.dyn.drei.com] has quit [] 20180417 00:52:22<+discordbot> @Pentarctagon yes, since I'd rather it be fixed instead 20180417 00:52:49<+discordbot> I think UNUSEDNOWARN needs to be moved after static 20180417 00:54:13<+discordbot> Alright. I'll try that after the current build finishes. 20180417 00:57:07<+discordbot> does that include the functions too? There's: inline static UNUSEDNOWARN std::string _(const char* str) but then below it: inline UNUSEDNOWARN static std::string _n(const char* str1, const char* str2, int n) 20180417 00:57:48<+discordbot> inline static UNUSEDNOWARN std::string is in the correct format I think 20180417 00:57:55<+discordbot> I think 20180417 00:58:07<+discordbot> it's also possible UNUSEDNOWARN needs to come before anything 20180417 00:58:10<+discordbot> ie 20180417 00:58:22<+discordbot> UNUSEDNOWARN inline static std::string 20180417 00:58:38<+discordbot> trial and error it is then 20180417 00:58:39<+discordbot> xD 20180417 00:58:52<+discordbot> come to think of it, the latter is probably more likely 20180417 01:02:27-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180417 01:16:31< mattsc> celticminstrel: I added a note to the Micro AI wiki page that the Goto MAI ignores tunnels in 1.14 when used with avoid_enemies= 20180417 01:16:45< mattsc> Will you document the new behavior of find_path when you are done with it? 20180417 01:17:19< celticminstrel> Was I not done with it? 20180417 01:17:45< mattsc> I don’t know. 20180417 01:18:26< mattsc> I also want to make a note about units not being recalled by default in 1.14 if the AI does not consider them worth it, but I am not sure where. 20180417 01:18:39< mattsc> Maybe wherever recall_cost is documented? 20180417 01:19:41< celticminstrel> Maybe? Or maybe in AI_Recruitment? 20180417 01:19:44< celticminstrel> Maybe even both? 20180417 01:19:46< celticminstrel> I dunno. 20180417 01:20:19< mattsc> Yeah, I’ll look around a bit. 20180417 01:21:07< mattsc> As for my previous question, whether you’re done with it or not, the question still applies (it doesn’t seem to be on the wiki yet, at least not where I looked) 20180417 01:21:59< mattsc> celticminstrel: also, did you see my PM? 20180417 01:22:28< celticminstrel> I did not. 20180417 01:24:17<+discordbot> celmin: unit_topic_generator should not use it 20180417 01:24:30<+discordbot> I'll just revert all the commits 20180417 01:24:39<+discordbot> T'was a dumb idea anyway 20180417 01:24:49<+discordbot> and it pushes the image to the left 20180417 01:24:55<+discordbot> since it's larger than 100 20180417 01:25:39< celticminstrel> Why shouldn't unit_topic_generator use it? 20180417 01:26:01<+discordbot> because it doesn't use the big portrait if it's just the unit image 20180417 01:26:23< celticminstrel> Oh, actually that makes sense, because it shows the unit image anyway. 20180417 01:28:52<+discordbot> but yeah, it doesn't look that great (no idea why it looks worse than in help) 20180417 01:28:57<+discordbot> and it gets shoved to the left 20180417 01:29:09<+discordbot> and I'm sure it would cause some weird-ass corner case bug 20180417 01:55:40< irker523> wesnoth: Charles Dang wesmere:master 6013cdc6725e / static/docroot/index.php: Updated frontpage links for 1.13.14 https://github.com/wesnoth/wesmere/commit/6013cdc6725ebb0d4c4edccd1fd3311e1fc2c881 20180417 01:55:49< celticminstrel> \o/ 20180417 01:55:53< celticminstrel> ANNOUNCEMENT! 20180417 01:58:24<+discordbot> oops, i messed up the topic 20180417 01:58:28<+discordbot> title 20180417 01:58:29<+discordbot> fuck 20180417 01:58:57<+discordbot> The channel description needs to be more specific. 20180417 01:59:45<+discordbot> this one? 20180417 01:59:54<+discordbot> Yes. 20180417 02:05:13<+discordbot> It has been done. 20180417 02:13:52-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Ping timeout: 256 seconds] 20180417 02:14:04-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180417 02:29:46< mattsc> celticminstrel: I added a comment about the recall change in default behavior here: https://wiki.wesnoth.org/SingleUnitWML#Unit_Data (under recall_cost) 20180417 02:30:15< mattsc> This is meant as a placeholder for now, until I have actually added the 1.15 behavior, just to document this. 20180417 02:30:54< mattsc> Adding it to the RCA AI recruitment CA description is pointless IMO, because nobody will ever see it there. 20180417 02:32:06< mattsc> I’ll also add it to the [side]recall_cost description. 20180417 02:33:08< mattsc> With that I think I am done with my changes to the wiki, unless I am forgetting something. 20180417 02:52:28-!- celmin [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180417 02:52:29-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Disconnected by services] 20180417 02:52:29-!- celmin is now known as celticminstrel 20180417 03:00:36< irker523> wesnoth: Iris Morelle wesnoth:1.14 e6b17f88cbcc / src/campaign_server/ (campaign_server.cpp campaign_server.hpp): campaignd: Refactor add-on deletion code into its own method https://github.com/wesnoth/wesnoth/commit/e6b17f88cbcc8a3d0ace43cddab603fa1cd90b91 20180417 03:00:39< irker523> wesnoth: Iris Morelle wesnoth:1.14 180995f46422 / src/campaign_server/campaign_server.cpp: campaignd: Add 'delete' control FIFO command https://github.com/wesnoth/wesnoth/commit/180995f46422661f0e1afd01a7b84cb3dafa3f24 20180417 03:00:42< irker523> wesnoth: Iris Morelle wesnoth:1.14 83afa195215d / src/campaign_server/campaign_server.cpp: campaignd: Add 'hide'/'unhide' control FIFO commands and hidden= attribute https://github.com/wesnoth/wesnoth/commit/83afa195215dc35a3cb892a6be836980c413b88f 20180417 03:00:45< irker523> wesnoth: Iris Morelle wesnoth:1.14 4d90a77aa8b1 / src/campaign_server/campaign_server.cpp: campaignd: Remove last remaining trace of the master_password functionality https://github.com/wesnoth/wesnoth/commit/4d90a77aa8b1431d00c0ecea40b73a1ef97e2711 20180417 03:01:10<+discordbot> (Yes, I will forward-port this.) 20180417 03:08:14< celticminstrel> BTW, are you planning to implement that addons manifest system at some point? Presumably not right in the very near future since we're hard at work on 1.14 and there will need to be at least a 1.14.1 soon after, but... 20180417 03:08:43<+discordbot> @Vultraz @Pentarctagon I quickly looked in the GCC manual about what __attribute__(unused) means. 20180417 03:08:52<+discordbot> "This attribute, attached to a function, means that the function is meant to be possibly unused. GCC does not produce a warning for this function." 20180417 03:09:44<+discordbot> IIRC, [[maybe_unused]] is completely different (it's used for function parameters which are allowed to be unused). 20180417 03:12:34<+discordbot> celticminstrel: I don't know for sure. So much has changed on the client side that it'll take me qute a while to get up to speed with it all and I can't say in advance whether I'll have time and energy for that. 20180417 03:17:16< celticminstrel> I just realized... I don't think the GUI2 WML uses the WML cache? It probably should be, since it's something that basically never changes. 20180417 03:21:43< celticminstrel> Though is the WML cache flexible enough to have two entirely separate caches? Because IIUC, doesn't it clear the WML cache whenever the active preprocessor defines change? 20180417 03:26:27<+discordbot> @jyrkive I see. Misunderstood,t hen. 20180417 03:33:38<+discordbot> The WML cache code is garbage. 20180417 03:34:07<+discordbot> I'm not just saying that, I tried my hardest to make sense of it when trying to debug the cache issue and it really doesn't make any at all. 20180417 03:34:35< celticminstrel> XD 20180417 03:34:49< celticminstrel> I kinda want to hear more. >_> 20180417 03:35:08<+discordbot> I don't remember the specifics, I just gave up on it and decided that it needed to be rewritten from the ground up, but never got around to doing so. 20180417 03:35:37< celticminstrel> I was looking in the cache code myself when working on the schema branch, but I didn't really look closely, just added schema stuff everywhere I needed to to get it to work... and then I ended up testing with --nocache so I suppose that work wasn't really that helpful. 20180417 03:35:51<+discordbot> I do know who wrote it and I'll say that he left us with an unprecedented technical debt at the time by completely crippling the AI at a time when no-one else understood the AI code (1.5.x). 20180417 03:36:01< celticminstrel> Ooh fun. 20180417 03:36:26<+discordbot> And disappeared after pushing that code, coincidentally. 20180417 03:36:39< celticminstrel> Did that code end up getting reverted? 20180417 03:37:24<+discordbot> Yeah. 20180417 03:37:52<+discordbot> The AI code in question, that is. It was kind of a refactoring mixed with bug fixes, hence the difficulty in reverting it. 20180417 03:38:45<+discordbot> During 1.7.x the entire AI code started to be rewritten by Crab_ so all that became little more than a historical note, but we got stuck with the unwieldy WML cache code. 20180417 03:40:20<+discordbot> I get the feeling that it was intended to be highly testable (the dev in question also brought us the original version of the unit tests suite IIRC) and the author forgot to document it and make it maintainable in the process. 20180417 03:41:14< celticminstrel> IIUC, it just caches preprocessed WML as text, right? 20180417 03:41:24< celticminstrel> Maybe gzipped or something. 20180417 03:41:35<+discordbot> But the fact that it suffers from code duplication in a few places makes that theory slightly questionable. 20180417 03:41:55<+discordbot> Yes, it caches preprocessed WML as gzipped WML. 20180417 03:42:09<+discordbot> Does caching preprocessed WML even speed things up? 20180417 03:42:16<+discordbot> I think it's in the parser input format with \xFE marker and everything. It's not too hard to check anyway. 20180417 03:42:20<+discordbot> *markers 20180417 03:42:25<+discordbot> WML parsing overhead, as well as the time to read it from disk, remains. 20180417 03:43:01< celticminstrel> Yeah, I was going to say, if you're having a cache, wouldn't just dumping out binary data be better? I mean it wouldn't be quite that simple since the in-memory form of this data is littered with pointers, but... 20180417 03:43:06<+discordbot> It sort of does in various edge cases (including terrain graphics WML, which at least before 1.13.x was very macro-expansion-heavy). 20180417 03:43:21< celticminstrel> Isn't it still very macro-expansion-heavy? 20180417 03:43:44<+discordbot> I don't know. It depends on whether #arg helps with that 20180417 03:44:24<+discordbot> Also, I believe the reason the binary serialization of WML was eventually removed is that it was found to not be as compressible as text WML . 20180417 03:44:49<+discordbot> I don't know if the dev who did that ever compared the parser performance of gzipped WML vs. binary WML though. 20180417 03:45:40< celticminstrel> Well yeah, binary data isn't as compressible in general, but why is the compressibility the important statistic here? 20180417 03:46:03< celticminstrel> If it's a cache I'd think the important point would be speed of parsing. 20180417 03:46:30<+discordbot> Indeed. If you want to save disk space, the best way is removing the cache entirely. 20180417 03:46:37< celticminstrel> Heh, indeed. 20180417 03:47:12< irker523> wesnoth/wesnoth:master Charles Dang 54cacf815d Changelog entry for 30257af AppVeyor: All builds passed 20180417 03:49:08<+discordbot> Probably because when reading from a rotating disk the amount of reads that need to be performed to fetch data becomes the bottleneck more quickly than the parsing of said data, at least in a best-case scenario. 20180417 03:50:04< celticminstrel> But also note that the binary format would most likely be more compressed to begin with. 20180417 03:50:06<+discordbot> That may not necessarily apply to Wesnoth (anymore), but this isn't exactly the most benchmarked game engine so... ¯_(ツ)_/¯ 20180417 03:50:13< celticminstrel> Though... I'm not sure by how much... 20180417 03:50:17<+discordbot> It wasn't though. 20180417 03:50:58< celticminstrel> By that I mean the raw text WML (uncompressed) would be larger than the binary serialization. 20180417 03:51:14<+discordbot> Yes, but it's handled in memory rather than on disk. 20180417 03:51:21< celticminstrel> Hmm? 20180417 03:52:26<+discordbot> Wesnoth reads a gzipped file and handles the uncompressed contents in memory. 20180417 03:53:08< celticminstrel> I feel like something didn't get conveyed properly in this conversation... 20180417 03:58:08< celticminstrel> So you were saying the binary serialization was originally abandoned because it was less compressible than the text serialization, but how do you measure compressibility? Normally it's by comparing filesize before and after, right? But a binary serialization should've been significantly smaller than the text serialization even before compression. So just how different was the compressibility? In theory it could've been possible that 20180417 03:58:09< celticminstrel> despite binary being less compressible, the compressed binary and text serializations come out to similar sizes. 20180417 03:58:35< celticminstrel> I have no knowledge of any of the specifics of the historical case, so this is pretty much pure speculation, though. 20180417 03:59:00<+discordbot> It's easily possible that the originally smaller format (binary) clocks in at a larger size after compression. 20180417 03:59:08< celticminstrel> Yeah, indeed. 20180417 04:03:02-!- aidanhs1 [~aidanhs@81.4.110.234] has joined #wesnoth-dev 20180417 04:03:09-!- aidanhs [~aidanhs@81.4.110.234] has quit [Ping timeout: 256 seconds] 20180417 04:03:38<+discordbot> That bug again D: 20180417 04:04:13< celticminstrel> ? 20180417 04:05:09<+discordbot> celticminstrel: https://github.com/wesnoth/wesnoth/issues/2912 20180417 04:05:23<+discordbot> There's a bot to notify us about new bug reports in the Discord side. 20180417 04:05:42-!- minzbonbon [~min@meta23.net] has quit [Ping timeout: 261 seconds] 20180417 04:05:52<+discordbot> A webhook posing as a bot, really. 20180417 04:05:54< celticminstrel> Oh image doesn't fit. 20180417 04:06:07-!- minzbonbon [~min@meta23.net] has joined #wesnoth-dev 20180417 04:06:26<+discordbot> I feel like I've seen at least four variation on the same bug in the same scenario over the years since the new portrait was added. 20180417 04:06:27<+discordbot> *s 20180417 04:06:33-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180417 04:06:45< celticminstrel> Oh. 20180417 04:07:22< celticminstrel> So it's not just "yet another image doesn't fit", it's "yet another report of that specific image in that campaign not fitting". 20180417 04:08:15<+discordbot> Yep. 20180417 04:09:20<+discordbot> Suggest removing that error 20180417 04:09:30<+discordbot> And what happens if it's ignored? 20180417 04:09:44<+discordbot> I would assume the image simply doesn't show 20180417 04:09:49< celticminstrel> IIRC, ignoring it causes some part of the UI to simply not show up. 20180417 04:10:13< celticminstrel> Which is still not good, but IMO probably better than a crash or even a boot to titlescreen. 20180417 04:10:23<+discordbot> The image could also be scaled down 20180417 04:10:42<+discordbot> by the message dialog specifically 20180417 04:10:46< celticminstrel> Maybe a proper fix would be to use multiple resolutions. 20180417 04:10:54<+discordbot> what??? 20180417 04:11:03< celticminstrel> So if you're in a tiny 800x600 window, all the portraits get scaled down by like, 80%. 20180417 04:11:08< celticminstrel> Otherwise, they don't. 20180417 04:11:22<+discordbot> mutters darkly 20180417 04:11:22< celticminstrel> @Vultraz - Multiple [resolution] tags I mean 20180417 04:11:31<+discordbot> I kind of thought that was the case already, with different numbers and using formulas instead. 20180417 04:12:07< celticminstrel> Hey, I presume mordante implemented that capability specifically for this sort of situation. 20180417 04:12:11<+discordbot> At least it's always seemed that the portrait scaling isn't linear. 20180417 04:12:24<+discordbot> I don't know what mordante was thinking 20180417 04:12:30< celticminstrel> Yeah you could do it in formulas too. 20180417 04:13:06<+discordbot> [resolution] was created to implement mobile and small form-factor device support. 20180417 04:13:31<+discordbot> So, yes, it applies here. 20180417 04:13:55<+discordbot> But I think it requires duplicating code (whether directly or using the preprocessor)? 20180417 04:14:01< celticminstrel> Yeah, it does. 20180417 04:14:05<+discordbot> heavily duplicating code 20180417 04:14:15< celticminstrel> You're basically defining the entire layout twice. 20180417 04:14:35<+discordbot> again. Don't know what mordante was thinking. 20180417 04:14:52<+discordbot> It seems he went for something that looked good on paper but sucks in practice 20180417 04:14:58< celticminstrel> Which also means you can use an entirely different layout in both cases, which is what we do in the MP Create screen the MP lobby. 20180417 04:15:20< celticminstrel> I forgot an "and" in that sentence. 20180417 04:15:22<+discordbot> The advantage of this approach is freedom. It allows completely different layouts for small form factors. 20180417 04:15:27< celticminstrel> Exactly. 20180417 04:15:34<+discordbot> I'd still like at some point to make layouts Just Work dynamically instead of having different layouts defined for each resolution 20180417 04:15:41< celticminstrel> Which like I said is what we do in... no point in repeating it though. 20180417 04:15:53<+discordbot> every new layout is a maintenance burden 20180417 04:16:01<+discordbot> and more WML to parse 20180417 04:16:09<+discordbot> ThemeWML's advantage in this case is that it allows defining partial resolution layouts. 20180417 04:16:19< celticminstrel> Yeah, if possible I'd agree it's better have more flexible layouts rather than different layouts. 20180417 04:16:23<+discordbot> Yes, it was one thing ThemeWML did right 20180417 04:16:39< celticminstrel> Oh yeah, if GUI2 [resolution] were expanded to have something like that, it'd be a lot more useful... 20180417 04:16:43<+discordbot> I assume it was in the plans for GUI2 but mordante got busy with... everythuing else. 20180417 04:16:57< celticminstrel> Though really, it wouldn't help much in MP Create and MP Lobby, I think. 20180417 04:17:02<+discordbot> And [resolution] became kind of irrelevant for a long time after TinyGUI support was removed. 20180417 04:17:09<+discordbot> And I suppose I hate on ThemeWML a lot, but I have come to recognize the usefulness of absolute and relative coordinate positioning 20180417 04:17:25<+discordbot> (TinyGUI was a compile-time option to support resolutions under 800x480.) 20180417 04:17:25<+discordbot> as opposed to grid based 20180417 04:17:27< celticminstrel> Coordinate positioning in general isn't good though. 20180417 04:17:48< celticminstrel> That's the major downside of GUI1. 20180417 04:18:06<+discordbot> depends on what you're doing 20180417 04:18:06<+discordbot> I suppose 20180417 04:18:07< celticminstrel> But certainly grid-based isn't always the best layout choice. 20180417 04:18:15<+discordbot> indeed 20180417 04:18:19<+discordbot> take the titlescreen 20180417 04:18:30<+discordbot> it's black magic even I dare not touch. 20180417 04:18:43<+discordbot> I'm surprised shadowm dared when she implemented the about button 20180417 04:18:52< celticminstrel> There are other useful layouts, like the north-south-east-west-centre layout (Java calls it BorderLayout), or flow layouts (which is basically what our listboxes do). 20180417 04:19:22<+discordbot> I messed with the titlescreen before in a couple of occasions. 20180417 04:19:46< celticminstrel> And while absolute coordinate systems are generally bad, a variation of that can still be useful, as UE's CanvasPanel demonstrates. 20180417 04:20:25<+discordbot> In some ways, GUI2 is well-designed. In others... It's an abomination. 20180417 04:20:34<+discordbot> One was to add the background colour (which you eventually removed) to the version label, which required me to mess with the layout because otherwise the background was much larger than the text. 20180417 04:20:58<+discordbot> I think the other was to fix an issue with the ToD box's layout resulting from my changes to the version label actually. 20180417 04:20:59<+discordbot> I honestly despise the amount of setup required to set up new dialogs and widgets 20180417 04:21:51<+discordbot> in anura, you create cfg file in FSON. That's it. Here you need at least the WML, the C++, the unit tests, the projectfile updates.... 20180417 04:21:59< celticminstrel> The title screen is actually one place in Wesnoth where something like UE's CanvasPanel would probably make the layout easier to understand, though you still have the downside of some sort of coordinates in that case... they're just not an absolute position on the canvas. 20180417 04:22:20<+discordbot> I've never been a fan of the amount of boilerplate code required to get a GUI2 dialog up. 20180417 04:22:59<+discordbot> But that could theoretically be improved and allow for a better implementation of the Lua API in the process. 20180417 04:23:02<+discordbot> oh, and you need to update the schema too 20180417 04:23:16< celticminstrel> No you don't. 20180417 04:23:20< celticminstrel> Not for adding a new dialog. 20180417 04:23:23<+discordbot> if you're adding a widget 20180417 04:23:24<+discordbot> That'd be for widgets only yeah. 20180417 04:23:28<+discordbot> or a new key 20180417 04:23:47<+discordbot> and if it's a dialog, if you don't add a unit test celmin is disappoint 20180417 04:24:17<+discordbot> You kind of need to do that to get unit tests though. 20180417 04:24:25<+discordbot> and you need to be sure you register the widget or dialog with the static registry 20180417 04:24:27<+discordbot> Because you want unit tests, surely? 20180417 04:24:41<+discordbot> and you need to be sure you declare the proper overridden functions like window_id 20180417 04:24:47<+discordbot> And as of this writing one of C++'s biggest deficiencies is the lack of a standarized reflection API. 20180417 04:24:51< celticminstrel> The boilerplate code for widgets though pales in comparison to that for dialogs. >_> 20180417 04:25:36<+discordbot> and you need to set up your pre_show/post_show stuff 20180417 04:25:36<+discordbot> and you need to optionally declare display wrappers 20180417 04:25:36 * celticminstrel notes that technically typeid counts as reflection. >_> 20180417 04:25:41<+discordbot> which thankfully I've relegated to variadic template macros (praise c++11) 20180417 04:25:44< celticminstrel> No you don't. 20180417 04:25:52<+discordbot> celticminstrel: Yeah but it's not very powerful. 20180417 04:26:05<+discordbot> seriously, how did people program anything in pre-c++11 20180417 04:26:06< celticminstrel> You don't necessarily need pre_show and post_show at all. 20180417 04:26:10<+discordbot> it must have been hell 20180417 04:26:12<+discordbot> GUI2 in particular has bigger requirements. 20180417 04:26:19< celticminstrel> True. 20180417 04:26:39<+discordbot> no lambdas.. no variadic templates... no auto... 20180417 04:26:44<+discordbot> no emplace 20180417 04:26:51<+discordbot> no std::to_string 20180417 04:27:16<+discordbot> Move semantics are a performance thing first and foremost. 20180417 04:27:16<+discordbot> What do you need emplace for? Just construct the object and push it. Two lines instead of one. 20180417 04:27:16<+discordbot> Not really "hell" in my book. 20180417 04:27:21< celticminstrel> typeid is about powerful enough reflection to implement variant and any, and that's about it. 20180417 04:27:32< celticminstrel> Yeah, I was going to say, emplace isn't really essential at all. 20180417 04:27:40<+discordbot> yes, emplace isn't that essential 20180417 04:27:42<+discordbot> it's convenient 20180417 04:27:58< celticminstrel> Variadic templates are huge. Lambdas are really nice but not really essential. 20180417 04:28:10< celticminstrel> std::to_string has always existed in some form or other. 20180417 04:28:18<+discordbot> it's the stuff like lambdas, variadic templates, auto, and constexpr that are essential 20180417 04:28:25< celticminstrel> Just create a std::stringstream and output to it. 20180417 04:28:34< celticminstrel> Constexpr isn't that big really? 20180417 04:28:41<+discordbot> And what do you need constexpr for? 20180417 04:28:54< celticminstrel> Auto certainly is helpful, though it really just saves a little typing in most cases. 20180417 04:29:03<+discordbot> The only situation where you need it is when you need to calculate the value of a template parameter. 20180417 04:29:08<+discordbot> I don't need it specifically, but I can see where it's useful (as it's already simplified the GUI2 dispatcher code) 20180417 04:29:13<+discordbot> Instead of lambdas we used classes as functors. 20180417 04:29:18< celticminstrel> Of course there are some edge cases where it saves a lot of typing, or even allows capturing variables with an unexpressible type. 20180417 04:30:09<+discordbot> The reason why constexpr simplified the GUI2 dispatcher code is that mordante insisted on doing a lot of the work at compile time, which required horrible templates without constexpr. 20180417 04:30:26<+discordbot> However, the code would have been perfectly readable if runtime checks were used instead. 20180417 04:30:56<+discordbot> Again, constexpr isn't a requirement for anything. It merely allowed that performance optimization to be made without horribly ugly code. 20180417 04:31:24<+discordbot> yes, there's something that I intend to move to a runtime check because it's a runtime check anyway and using templates has bloated the code to hell, but I haven't figured out how best to do it yet. 20180417 04:33:37<+discordbot> at times it seems mordante designed things cleverly, but not readably. 20180417 04:33:40< celticminstrel> IMO? Don't bother. 20180417 04:33:43<+discordbot> or practically 20180417 04:33:51< celticminstrel> At least not until everything is working smoothly. 20180417 04:34:19-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer] 20180417 04:41:46-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has joined #wesnoth-dev 20180417 04:41:46-!- noy_ [~Noy@S01067cb21b205894.vs.shawcable.net] has quit [Changing host] 20180417 04:41:46-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20180417 04:44:26-!- noy_ [~Noy@wesnoth/developer/noy] has quit [Quit: noy_] --- Log opened Tue Apr 17 05:26:42 2018 20180417 05:26:50-!- lobby [~wesnoth@wesnoth/bot/lobby] has joined #wesnoth-dev 20180417 05:26:50-!- Topic for #wesnoth-dev: 1.14.0 ANNOUNCEMENT ON MAY 1ST, tag on April 25th (times TBD) | String and feature freeze on 1.14 branch | Wesnoth Developers Channel | >>> Want to help? Go here: https://r.wesnoth.org/t42911 (and thanks!) <<< | Discord Server: https://discord.gg/battleforwesnoth | Logs: http://irclogs.wesnoth.org | Bug tracker: https://bugs.wesnoth.org 20180417 05:26:50-!- Topic set by shadowm [~iris@wesnoth/developer/shadowm] [Mon Apr 16 08:26:30 2018] 20180417 05:26:50[Users #wesnoth-dev] 20180417 05:26:50[+discordbot ] [ EliDupree ] [ Jetrel_bot ] [ Rhonda ] 20180417 05:26:50[ aeth ] [ esr ] [ lobby ] [ shadowm ] 20180417 05:26:50[ AI0867 ] [ galegosimpatico] [ loonycyborg ] [ Soliton ] 20180417 05:26:50[ aidanhs1 ] [ Gambit ] [ matthiaskrgr] [ TC01 ] 20180417 05:26:50[ APic ] [ heirecka ] [ minzbonbon ] [ TheJJ ] 20180417 05:26:50[ Appleman1234 ] [ higgins ] [ nore ] [ timotei__] 20180417 05:26:50[ celticminstrel ] [ iceiceice ] [ nurupo ] [ vihta ] 20180417 05:26:50[ commavir ] [ irker523 ] [ oldlaptop ] [ vincent_c] 20180417 05:26:50[ crimson_penguin] [ Ivanovic ] [ Polsaker ] 20180417 05:26:50[ DDR ] [ iwaim ] [ pydsigner ] 20180417 05:26:50[ elias ] [ janebot ] [ Ravana_ ] 20180417 05:26:50-!- Irssi: #wesnoth-dev: Total of 41 nicks [0 ops, 0 halfops, 1 voices, 40 normal] 20180417 05:26:50-!- Home page for #wesnoth-dev: https://www.wesnoth.org 20180417 05:27:16-!- Channel #wesnoth-dev created Tue Jan 27 05:28:41 2009 20180417 05:28:06-!- Irssi: Join to #wesnoth-dev was synced in 84 secs 20180417 05:28:36-!- Kawa[m] [kawamatrix@gateway/shell/matrix.org/x-nxgxtcdyufuqnizh] has joined #wesnoth-dev 20180417 05:32:05< irker523> wesnoth/wesnoth:master Charles Dang 98ed802290 Fixup 601c67d970c2eac AppVeyor: All builds passed 20180417 05:33:04-!- madmax28 [madmax28ma@gateway/shell/matrix.org/x-btxdgmivdhidepoe] has joined #wesnoth-dev 20180417 05:34:10<+discordbot> Just C++ things :| Error C2440 'return': cannot convert from 'gui2::event::dispatcher::signal_type' to 'gui2::event::dispatcher::signal_type' 20180417 05:34:28< celticminstrel> Probably with differen T on both sides. 20180417 05:34:34< celticminstrel> ^different 20180417 05:35:04< celticminstrel> Either that or there's somehow two distinct definitions of gui2::event::dispatcher::signal_type in the code. 20180417 05:35:16< celticminstrel> If that's even possible, I'm not sure. 20180417 05:35:36<+discordbot> oh yeah, T is different 20180417 05:36:46<+discordbot> 1> with 1> [ 1> T=gui2::event::signal_function 1> ] 1> and 1> [ 1> T=item 1> ] 20180417 05:38:19-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20180417 05:38:35<+discordbot> oh, I see the problem 20180417 05:39:18-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180417 05:41:10-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Client Quit] 20180417 05:41:33<+discordbot> template function with varying return valye 20180417 05:41:34<+discordbot> value 20180417 05:41:36<+discordbot> a no-no 20180417 05:41:42<+discordbot> though.. 20180417 05:41:46<+discordbot> it's the only one...? 20180417 05:41:50<+discordbot> so it should work.. 20180417 05:41:53-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180417 05:41:59<+discordbot> or wait 20180417 05:42:25-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-qazpnovytdoqjlhd] has joined #wesnoth-dev 20180417 05:42:56-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Client Quit] 20180417 05:43:42< irker523> wesnoth: Iris Morelle wesnoth:master 957be8b53edb / src/campaign_server/ (campaign_server.cpp campaign_server.hpp): campaignd: Refactor add-on deletion code into its own method https://github.com/wesnoth/wesnoth/commit/957be8b53edbdce7706491bb4dd7f64de27784a9 20180417 05:43:43-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180417 05:43:45< irker523> wesnoth: Iris Morelle wesnoth:master 0475c349b801 / src/campaign_server/campaign_server.cpp: campaignd: Add 'delete' control FIFO command https://github.com/wesnoth/wesnoth/commit/0475c349b801643a18372bb810ab0b6f4fd97fe8 20180417 05:43:48< irker523> wesnoth: Iris Morelle wesnoth:master 7d5d7ee7d429 / src/campaign_server/campaign_server.cpp: campaignd: Add 'hide'/'unhide' control FIFO commands and hidden= attribute https://github.com/wesnoth/wesnoth/commit/7d5d7ee7d429a9d650d300311d2bfeb363ca4686 20180417 05:43:51< irker523> wesnoth: Iris Morelle wesnoth:master 6d5f5d4299f4 / src/campaign_server/campaign_server.cpp: campaignd: Remove last remaining trace of the master_password functionality https://github.com/wesnoth/wesnoth/commit/6d5f5d4299f41f54c979d2a5b785b4b26b9d2be2 20180417 05:44:32-!- celticminstrel is now known as celmin|sleep_stu 20180417 05:44:42-!- shadowm changed the topic of #wesnoth-dev to: 1.14.0 tag on April 25th (time TBD), announcement on May 1st (Steam launch 6 pm PST) | String and feature freeze on 1.14 branch | Wesnoth Developers Channel | >>> Want to help? Go here: https://r.wesnoth.org/t42911 (and thanks!) <<< | Discord Server: https://discord.gg/battleforwesnoth | Logs: http://irclogs.wesnoth.org | Bug tracker: https://bugs.wesnoth.org 20180417 05:45:03-!- syrma[m] [syrmamatri@gateway/shell/matrix.org/x-qpidorhgqfsdptck] has joined #wesnoth-dev 20180417 05:52:29<+discordbot> oh, the problem is that the template return type depends on a runtime check 20180417 06:06:47-!- gallaecio [~quassel@119.red-83-34-169.dynamicip.rima-tde.net] has joined #wesnoth-dev 20180417 06:19:34-!- travis-ci [~travis-ci@ec2-107-21-150-51.compute-1.amazonaws.com] has joined #wesnoth-dev 20180417 06:19:35< travis-ci> Pentarctagon/wesnoth#432 (travis-17 - 9e99266 : pentarctagon): The build failed. 20180417 06:19:35< travis-ci> Build details : https://travis-ci.org/Pentarctagon/wesnoth/builds/367491815 20180417 06:19:35-!- travis-ci [~travis-ci@ec2-107-21-150-51.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180417 06:34:07<+discordbot> @Vultraz @jyrkive Putting UNUSEDNOWARN in front of everything else worked, in as much as the warnings are gone. Whether or not they are meant to accomplish different things, someone else will have to say though. Also, to get c++17 building successfully, I had to additionally revert the last two changes to src/serialization/string_view.hpp due this error: https://travis-ci.org/wesnoth/wesnoth/jobs/367438657#L1223 which I 20180417 06:34:08<+discordbot> assume has something to do with the #ifndef starting here: https://github.com/wesnoth/wesnoth/blob/master/src/serialization/string_view.hpp#L181 20180417 06:35:46<+discordbot> OK, so std::string_view didn't simply copy the API of boost::string_view without changes. 20180417 06:36:08<+discordbot> @Vultraz I'd appreciate if you didn't make changes like that without testing that they compile. 20180417 06:36:20<+discordbot> Fair enough 20180417 06:36:25<+discordbot> I'll start building with c++17 20180417 06:36:45<+discordbot> Using the MSVC option to use C++17 mode? 20180417 06:36:51<+discordbot> yes 20180417 06:37:01<+discordbot> Sounds good. 👍 20180417 06:39:51<+discordbot> BTW, the existing HAVE_CXX17 implementation won't work on MSVC. 20180417 06:39:52<+discordbot> https://github.com/wesnoth/wesnoth/blob/master/src/global.hpp#L37-L39 20180417 06:40:34<+discordbot> MSVC doesn't change the value of __cplusplus depending on the C++ version. Microsoft wants 100% conformance with the C++ standard before increasing the value. 20180417 06:40:53<+discordbot> _MSVC_LANG should be used instead: https://msdn.microsoft.com/en-us/library/b0084kay.aspx 20180417 06:42:49<+discordbot> I see 20180417 06:47:52<+discordbot> As far as the PR then, is it acceptable as-is? I obviously don't have the knowledge necessary to write a fix to the two commits I've currently reverted as part of it. Otherwise, the only other thing I'd like to do is enable strict mode, so warnings like the gettext spam are treated as actual errors. 20180417 06:48:02<+discordbot> @jyrkive maybe you could commit that change (to the HAVE_CXX17 define) 20180417 06:48:21<+discordbot> @Pentarctagon Yes, your PR is acceptable in its current state. 20180417 06:48:37<+discordbot> @Vultraz Sure, I can do that. 20180417 06:49:00<+discordbot> (If we really want HAVE_CXX17 defined with a partial C++17 implementation, anyway.) 20180417 06:49:43<+discordbot> 2017's implementation is fairly completely 20180417 06:50:13<+discordbot> complete 20180417 07:05:15-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180417 07:15:15<+discordbot> No-one mentioned the new MP maps in the outline. 😃 20180417 07:15:42<+discordbot> https://github.com/wesnoth/wesnoth/commit/fafce20db418de9698e8eaf504b975d64578fd95 20180417 07:36:18< irker523> wesnoth: pentarctagon wesnoth:master 33ad6be326c2 / / (5 files in 3 dirs): Adds a c++17 build using the pre-release Ubuntu 18.04. https://github.com/wesnoth/wesnoth/commit/33ad6be326c234b173d680ce34589464f88f8418 20180417 07:36:20< irker523> wesnoth: pentarctagon wesnoth:master 5dd5b6ec0b5d / src/serialization/base64.cpp: Attempt to fix travis error. https://github.com/wesnoth/wesnoth/commit/5dd5b6ec0b5d8272416ef7dea40a93b5fcccba5d 20180417 07:36:22< irker523> wesnoth: pentarctagon wesnoth:master 298f1dc9c161 / src/gettext.hpp: Attempt to fix UNUSEDNOWARN travis+gcc warnings. https://github.com/wesnoth/wesnoth/commit/298f1dc9c1615196f73827e652ec2ea5f5ae5d9b 20180417 07:36:24< irker523> wesnoth: pentarctagon wesnoth:master 479d5fd01f45 / src/ (config.hpp serialization/string_view.hpp): Revert "Expand and fixup 00d87f8" https://github.com/wesnoth/wesnoth/commit/479d5fd01f4598ff54244c20074cdc27a1d630fa 20180417 07:36:26< irker523> wesnoth: pentarctagon wesnoth:master fed813ef346a / src/serialization/string_view.hpp: Revert "String View: use std::string_view on C++17 (untested)" https://github.com/wesnoth/wesnoth/commit/fed813ef346a6d657d41e35a83d7041b2dc06bef 20180417 07:36:28< irker523> wesnoth: pentarctagon wesnoth:master dd4b525c4028 / utils/travis/docker_run.sh: Make the C++17 build fail on warnings. https://github.com/wesnoth/wesnoth/commit/dd4b525c402879c9b67f799e634c5c172b49ee97 20180417 07:40:37<+discordbot> you... reverted everything 20180417 07:40:40<+discordbot> alright 20180417 07:40:55<+discordbot> well, the gettext thing jyrki said was incorrect 20180417 07:41:23<+discordbot> and I guess I'll re-add the string view stuff once I get it working 20180417 07:43:41<+discordbot> Are you sure you'll get it working? 20180417 07:44:00<+discordbot> We now know that boost::string_view and std::string_view have different API. 20180417 07:44:27<+discordbot> It's difficult, if not impossible, to get the game to use both depending on conditional compilation. 20180417 07:44:53<+discordbot> And to be frank, you don't really gain anything by conditionally using std::string_view. You make the code more complex, not less. 20180417 07:45:44<+discordbot> I'll look at the standard api and see. 20180417 07:52:37-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180417 07:55:01-!- grzywacz [~karol@89-70-226-147.dynamic.chello.pl] has joined #wesnoth-dev 20180417 08:14:32-!- Rhonda [~rhonda@anguilla.debian.or.at] has quit [Changing host] 20180417 08:14:32-!- Rhonda [~rhonda@wesnoth/developer/rhonda] has joined #wesnoth-dev 20180417 08:21:25-!- vladimirslavik [vslavik@nat/redhat/x-cqoinuoiyqopntke] has joined #wesnoth-dev 20180417 08:21:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180417 08:34:42<+discordbot> looks like mordante's reliance on build-time stuff might have served an actual purpose 20180417 08:34:44<+discordbot> 🤔 20180417 08:34:54<+discordbot> What do you mean? 20180417 08:36:04<+discordbot> I've refactored the code I was talking about earlier to use purely runtime checks. Scrollwheel events are broken (which I think is just me messing up the logic), but it seems possible to end up with event lag... 20180417 08:36:43<+discordbot> Huh. I wouldn't have thought it would become a bottleneck. 20180417 08:37:00<+discordbot> I'll have to see once I get this logic sorted 20180417 08:39:37<+discordbot> ah 20180417 08:39:38<+discordbot> there 20180417 08:39:41<+discordbot> got it fixed 20180417 08:40:10<+discordbot> I have to remember there's a difference between if(foo && bar) { return true; } and if(foo) { return bar; } 😛 20180417 08:42:49<+discordbot> events seem all fast now 20180417 08:42:53<+discordbot> guess it was jus my bad logic 20180417 08:43:28<+discordbot> Excellent. 👍 We'll finally get rid of that horrible template mess. 20180417 08:44:10<+discordbot> gonna get dinner, will come back, clean up, and push 20180417 09:08:41< irker523> wesnoth/wesnoth:master pentarctagon d1abe2bd10 Revert "Gettext: used [[maybe_unused]] f AppVeyor: All builds passed 20180417 09:53:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180417 10:26:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180417 10:29:10<+discordbot> ok, I messed up the logic here again... 20180417 10:29:17<+discordbot> tries to figure out the problem... 20180417 10:29:59<+discordbot> ok, so if I have a certain block of code set to this, it works: 20180417 10:30:04<+discordbot> cpp const auto queue_check = [&](auto& queue_set) { if((queue_type & dispatcher::pre) && !queue_set.queue[event].pre_child.empty()) { return true; } if((queue_type & dispatcher::child) && !queue_set.queue[event].child.empty()) { return true; } if((queue_type & dispatcher::post) && !queue_set.queue[event].post_child.empty()) { 20180417 10:30:04<+discordbot> return true; } return false; }; 20180417 10:30:20<+discordbot> but if it's return !queue_set.queue[event].empty(queue_type); it does not work... 20180417 10:30:27<+discordbot> where the implementation of empty here is 20180417 10:30:35<+discordbot> cpp if((queue_type & dispatcher::pre) && pre_child.empty()) { return true; } if((queue_type & dispatcher::child) && child.empty()) { return true; } if((queue_type & dispatcher::post) && post_child.empty()) { return true; } return false; 20180417 10:30:38<+discordbot> 🤔 20180417 10:30:44<+discordbot> what am I missing... 20180417 10:31:22<+discordbot> let's see 20180417 10:31:50<+discordbot> first block, if you returned the result of queue_check and it hit the first condition, ie, pre and pre NOT empty, you'd get true 20180417 10:31:57<+discordbot> with the second, ... 20180417 10:32:09<+discordbot> pre and pre IS empty, true, but inverted to false.. 20180417 10:32:11<+discordbot> hmmmmm 20180417 10:32:49<+discordbot> let's get rid of the ! 20180417 10:33:15<+discordbot> no, that.. doesn't work >_> 20180417 10:33:40<+discordbot> or, wait, I might need to move the condition to the if block here too 20180417 10:33:42<+discordbot> lemme try that 20180417 10:34:36<+discordbot> no, same problem 20180417 10:35:03<+discordbot> The upper implementation returns true it any of the queues is not empty. 20180417 10:35:25<+discordbot> The lower one returns true if any of them is empty. 20180417 10:36:00<+discordbot> here's the analogous block in master: https://github.com/wesnoth/wesnoth/blob/master/src/gui/core/event/dispatcher_private.hpp#L150-L168 20180417 10:36:23<+discordbot> first impl, I think 20180417 10:36:48<+discordbot> Same thing: it returns true if any of the queues is not empty. 20180417 10:36:57<+discordbot> hm 20180417 10:37:00<+discordbot> ok, I think I know what to do 20180417 10:38:49<+discordbot> another lengthy rebuild 20180417 10:39:21<+discordbot> unfortunate side effect of implementing the empty function in disptcher.hpp 😬 20180417 10:52:08<+discordbot> \o/ 20180417 10:52:55< irker523> wesnoth: Charles Dang wesnoth:master 0b45363c9589 / src/gui/core/event/ (dispatcher.cpp dispatcher.hpp dispatcher_private.hpp handler.cpp handler.hpp): GUI2: finished refactoring out usage of boost::mpl https://github.com/wesnoth/wesnoth/commit/0b45363c9589c14984eed393305b3a5ac59b71ec 20180417 10:52:58<+discordbot> there we go 20180417 10:58:20<+discordbot> ...oops 20180417 10:58:29<+discordbot> I included a bunch of stuff I didn’t mean to include 20180417 11:00:27<+discordbot> (if you're reviewing the commit ignore anything in handler.cpp) 20180417 11:01:04< irker523> wesnoth: Charles Dang wesnoth:master 1ec2de449e93 / src/gui/core/event/handler.cpp: Revert some changes from 0b45363 I didn't mean to commit https://github.com/wesnoth/wesnoth/commit/1ec2de449e93eccb73f95207214e8ca7b8bad217 20180417 11:09:24<+discordbot> I must say, extended constexpr is proving to be quite useful 20180417 11:09:57<+discordbot> or, rather, auto lambdas 20180417 11:10:01<+discordbot> sorry 20180417 11:10:02<+discordbot> wrong thing 20180417 11:10:03<+discordbot> xD 20180417 11:10:11<+discordbot> 😬 20180417 11:20:03< irker523> wesnoth/wesnoth:1.14 Iris Morelle 4d90a77aa8 campaignd: Remove last remaining trace o AppVeyor: All builds passed 20180417 12:14:31<+discordbot> hello guys and girls! any news on the updates for the iOS versions of Wesnoth (iPhone/iPad)? 20180417 12:27:37<+discordbot> @sinda is little busy these days so not much. I don't to promise anything what is not my problem (I am not iOS maintainer) but I believe that <@283792983545872395> will be able to release functional Wesnoth 1.14.0 for iPad to AppStore without any problems. Regarding to iPhone version, I have working prototype of wesnoth 1.13.13 on my iPhone 5S, fully playable, but only thanks to many workarounds... 20180417 12:27:41<+discordbot> @Vultraz seems removing dependency checks for boost thread broke builds using system boos 20180417 12:28:00<+discordbot> Wesnoth is not prepared for tiny mobile screens yet 😦 20180417 12:28:11<+discordbot> @iji Answer to your question ^^ 20180417 12:28:43<+discordbot> boost.locale depends on boost.thread 20180417 12:28:54<+discordbot> I don't see a way to remove that dependency either 20180417 12:29:24<+discordbot> boost.locale? and how is boost.locale lib called? 20180417 12:29:39<+discordbot> libboost_locale 20180417 12:30:05<+discordbot> I see, we have this library on macOS, let me check 20180417 12:31:24<+discordbot> Ok, libboost_locale don't have to depend on libboost_threads: otool -L libboost_locale-mt.dylib libboost_locale-mt.dylib: @executable_path/../Frameworks/libboost_locale-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) 20180417 12:31:24<+discordbot> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4) 20180417 12:31:45<+discordbot> You just have to rebuild boost libs without threads enabled 20180417 12:32:23<+discordbot> But you are using steam related stuff, right? 20180417 12:32:39<+discordbot> it affects both steam and flatpak 20180417 12:33:04<+discordbot> and how exactly did you disable threads in boost? 20180417 12:33:32<+discordbot> https://github.com/hrubymar10/MacCompileStuff/blob/master/SourcesAndScripts/Scripts/boost_build#L86 20180417 12:33:56<+discordbot> I am building libs myself so I just didn't included it at the beggining 20180417 12:34:03<+discordbot> whole story 20180417 12:34:35<+discordbot> You can also check this commit: https://github.com/hrubymar10/MacCompileStuff/commit/30ac90f382b35949c3b3a8213174c1e91013a5fe#diff-32680e75b4f20eb1f04ff7305d49d4e2 20180417 12:35:23<+discordbot> threading=multi? 20180417 12:36:27<+discordbot> yep, otherwise it is single thread only. and that's why all macOS' boost libs have -mt suffix 20180417 12:37:07<+discordbot> well I think it has threading=multi by default 20180417 12:37:32<+discordbot> I'll check documentation, gimme sec 20180417 12:39:06<+discordbot> you're making dylibs anyway 20180417 12:39:10<+discordbot> I'm building static 20180417 12:39:53<+discordbot> and it appears that if those libs aren't linked in explicitly there will be errors referencing boost.system and boost.thread if they're not linked against 20180417 12:40:13<+discordbot> shared libs are different because they can handle such indirect dependencies on their own 20180417 12:40:28<+discordbot> while a static lib is just a bundle of object files 20180417 12:45:35<+discordbot> I builded static boost lib using my script, how can I show dopendences? Is there any way except linker? 20180417 12:46:29<+discordbot> Try the ldd command. 20180417 12:46:46<+discordbot> https://linux.die.net/man/1/ldd 20180417 12:47:25<+discordbot> 😭 -bash: ldd: command not found 20180417 12:48:00<+discordbot> and btw ldd - print shared library dependencies I need it for static dependencies 20180417 12:48:29<+discordbot> Why would you need to know static dependencies? 20180417 12:48:54<+discordbot> Static dependencies are already linked into the binary. They do not need to be present anywhere else in the system. 20180417 12:49:48<+discordbot> because @Kawaii Loli talked about static dependencies. Tried build them myself to see, if they will depend on libbbost_thread 20180417 12:50:36<+discordbot> I don't think that libboost_locale depends on libboost_thread 20180417 12:50:47<+discordbot> It depends on libboost_thread only if libboost_thread is a shared dependency. 20180417 12:50:48<+discordbot> At least on macOS with my build script 20180417 12:51:22<+discordbot> I builded these libs using: ./bootstrap.sh --with-libraries=chrono,filesystem,iostreams,locale,program_options,random,regex,system,timer,test 20180417 13:03:34-!- vslavik [vslavik@nat/redhat/x-vzxnnolcccisusej] has joined #wesnoth-dev 20180417 13:06:22-!- vladimirslavik [vslavik@nat/redhat/x-cqoinuoiyqopntke] has quit [Ping timeout: 264 seconds] 20180417 13:52:27<+discordbot> for what is chrono needed? 20180417 13:55:03<+discordbot> also, couldn't build with c++17 myself, I need to rebuild boost... 20180417 13:56:03<+discordbot> I wonder if it's time to set up that dependency package repo. Or we need to figure out some way to handle c++17-compatible boost in external/ 20180417 13:56:43<+discordbot> Hmm. If we need a separate C++17 Boost build, we likely need a separate branch for that in the dependency repo. 😦 20180417 13:58:42<+discordbot> Indeed 20180417 14:11:05-!- vslavik__ [vslavik@nat/redhat/x-pqngencxpoeayitk] has joined #wesnoth-dev 20180417 14:14:10-!- vslavik [vslavik@nat/redhat/x-vzxnnolcccisusej] has quit [Ping timeout: 264 seconds] 20180417 14:20:26-!- irker523 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180417 14:29:13-!- irker865 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180417 14:29:13< irker865> wesnoth/wesnoth:master pentarctagon dd4b525c40 Make the C++17 build fail on warnings. AppVeyor: All builds passed 20180417 14:41:10< irker865> wesnoth: Charles Dang wesnoth:master c57a175fee70 / src/lexical_cast.hpp: Lexical Cast: remove use of boost::mpl https://github.com/wesnoth/wesnoth/commit/c57a175fee701b4d19c09653a5c9445b778d139e 20180417 14:43:30<+discordbot> Could probably remove mpl from scripting/push_check.hpp but I'm not sure how, and it's still needed for the tests until Boost 1.67 (where BOOST_AUTO_TEST_CASE_TEMPLATE now accepts a tuple instead of an mpl vector) 20180417 14:49:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180417 14:49:18-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180417 14:58:09-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev 20180417 14:59:48< irker865> wesnoth: Charles Dang wesnoth:master 28b1ab286123 / changelog.md src/scripting/lua_unit.cpp: Revert "Utilized 2x xBRZ scaling for portraitless units in game dialog" https://github.com/wesnoth/wesnoth/commit/28b1ab286123a415398a3626601642bed51027f0 20180417 15:00:20-!- vslavik__ [vslavik@nat/redhat/x-pqngencxpoeayitk] has quit [Quit: Leaving] 20180417 15:01:30< irker865> wesnoth: Charles Dang wesnoth:1.14 5e136419fec4 / changelog.md src/scripting/lua_unit.cpp: Revert "Utilized 2x xBRZ scaling for portraitless units in game dialog" https://github.com/wesnoth/wesnoth/commit/5e136419fec40b28df59747114f8b7eb37eaafcf 20180417 15:01:48<+discordbot> Might revisit that particular experiment at some point but for now it just didn't work 20180417 15:39:16-!- gallaecio [~quassel@119.red-83-34-169.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 20180417 15:42:25-!- travis-ci [~travis-ci@ec2-54-92-178-164.compute-1.amazonaws.com] has joined #wesnoth-dev 20180417 15:42:26< travis-ci> wesnoth/wesnoth#17678 (master - 28b1ab2 : Charles Dang): The build was broken. 20180417 15:42:26< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/367695772 20180417 15:42:26-!- travis-ci [~travis-ci@ec2-54-92-178-164.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180417 15:44:38<+discordbot> @hrubymar10 , ldd is Linux utility that does more or les what otool -L does on Mac. 20180417 15:45:47<+discordbot> I guess that even a static boost-locale will depend on boost-thread only when certain compilation flag is set. 20180417 15:48:02<+discordbot> I don't think so 20180417 15:48:15<+discordbot> unless you go for threading=single 20180417 15:48:22<+discordbot> I'm not sure if it's viable with wesnoth 20180417 15:48:28<+discordbot> wesnoth is using threads 20180417 16:02:31-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180417 16:26:21<+discordbot> @Vultraz What you could try would be 2x or 3x scaling for unit talking who have not portraits 20180417 16:26:55<+discordbot> I had this with some UMC, was looking better 20180417 16:27:03<+discordbot> I did try 2x 20180417 16:28:18<+discordbot> wait, the commit you reverteed is sth else... you implemented it a few days ago iirc? 20180417 16:28:44<+discordbot> Yes 20180417 16:28:52<+discordbot> It’s the same thing 20180417 16:29:04<+discordbot> Added, moved, and reverted 20180417 16:29:16<+discordbot> And great, now the lexical cast tests are failing 20180417 16:29:18<+discordbot> Gdi 20180417 16:32:02-!- gfg [~androirc@134.76.63.8] has joined #wesnoth-dev 20180417 16:38:35<+discordbot> unless std::is_same doesn't match T* with T* I don't know why it would fall back to generic. 20180417 16:39:06-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev 20180417 16:41:58<+discordbot> @loonycyborg I'm sure it's necessary, as most work in Wesnoth is done in a single thread. But I agree that, in the end, better safe than sorry. 20180417 16:50:38<+discordbot> huh 20180417 16:50:39<+discordbot> this fails 20180417 16:50:42<+discordbot> static_assert(std::is_same>::value, "foooo"); 20180417 16:50:43<+discordbot> 🤔 20180417 16:50:50<+discordbot> why... 20180417 16:51:01<+discordbot> @Vultraz Unlike I said earlier, I won't be making the "define HAVE_CXX17 when Visual Studio is in C++17 mode" change today. 20180417 16:51:19<+discordbot> Turns out that my copy of VS2017 has broken yet again and needs a reinstall. 20180417 16:51:31<+discordbot> I'm not willing to spend the time to do that now. 20180417 16:51:32<+discordbot> no prob 20180417 16:51:34<+discordbot> no rush 20180417 16:51:42<+discordbot> low priority 20180417 16:53:10<+discordbot> ok, so static_assert(std::is_same>::value, "foooo"); DOES match. So it's something about the pointer type 🤔 20180417 16:53:16<+discordbot> very odd 20180417 16:53:39<+discordbot> Maybe it's removing a wrong const. 20180417 16:53:49< Soliton> try: static_assert(std::is_same>::value, "foooo"); 20180417 16:53:58<+discordbot> Does static_assert(std::is_same>::value, "foooo"); pass? 20180417 16:55:08<+discordbot> both of those work 20180417 16:55:20<+discordbot> All right. 20180417 16:55:44<+discordbot> It means that std::remove_const_t removes constness of the pointer. 20180417 16:55:57<+discordbot> Not the underlying character array. 20180417 16:56:04<+discordbot> It says "topmost const" 20180417 16:56:16<+discordbot> I guess I misunderstood that 20180417 16:59:03<+discordbot> I wonder what a good way to match either char* or const char* is... suppose I could remove the pointer and just check against char 20180417 16:59:44<+discordbot> Well, the previous way with boost::mpl wasn't bad. 20180417 17:00:29<+discordbot> I'll ponder this tomorrow 20180417 17:13:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180417 17:13:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180417 17:17:15< irker865> wesnoth/wesnoth:master Charles Dang 1ec2de449e Revert some changes from 0b45363 I didn' AppVeyor: All builds passed 20180417 17:21:03-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection] 20180417 17:38:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180417 17:39:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180417 18:12:45-!- octalot [~steve@77.119.130.139.wireless.dyn.drei.com] has joined #wesnoth-dev 20180417 18:13:28<+discordbot> wesnoth on steam OuO 20180417 19:27:04< irker865> wesnoth: Jyrki Vesterinen wesnoth:1.14 8a0027691363 / / (9 files in 5 dirs): Implement saving MP chat message history (#1194, #2802) https://github.com/wesnoth/wesnoth/commit/8a0027691363c05fa06657f8c4e466054a530fda 20180417 19:27:06< irker865> wesnoth: Jyrki Vesterinen wesnoth:1.14 9646434bc10c / changelog.md players_changelog.md: Changelog entry for commit 8a00276913 https://github.com/wesnoth/wesnoth/commit/9646434bc10cb68177dc8864a1ed9ede426cac8f 20180417 19:31:59< irker865> wesnoth: Jyrki Vesterinen wesnoth:master a02100a0f15b / / (9 files in 5 dirs): Implement saving MP chat message history (#1194, #2802) https://github.com/wesnoth/wesnoth/commit/a02100a0f15bd015c2322b7b528b0b9b60a1c678 20180417 19:32:01< irker865> wesnoth: Jyrki Vesterinen wesnoth:master fc3ca7a78371 / changelog.md players_changelog.md: Changelog entry for commit a02100a0f1 https://github.com/wesnoth/wesnoth/commit/fc3ca7a78371dd552f937091bf8929c434b3b8de 20180417 19:33:05-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev 20180417 19:42:52< Ravana_> https://github.com/wesnoth/wesnoth/issues/1366 seems duplicate of https://github.com/wesnoth/wesnoth/issues/2473, I think first should be linked to second and closed 20180417 20:00:06-!- gallaecio [~quassel@188.79.96.255] has quit [Remote host closed the connection] 20180417 20:08:53-!- travis-ci [~travis-ci@ec2-54-92-178-164.compute-1.amazonaws.com] has joined #wesnoth-dev 20180417 20:08:54< travis-ci> wesnoth/wesnoth#17681 (master - fc3ca7a : Jyrki Vesterinen): The build is still failing. 20180417 20:08:54< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/367820469 20180417 20:08:54-!- travis-ci [~travis-ci@ec2-54-92-178-164.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180417 20:55:22-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection] 20180417 21:09:32< irker865> wesnoth/wesnoth:master Charles Dang 28b1ab2861 Revert "Utilized 2x xBRZ scaling for por AppVeyor: All builds passed 20180417 21:33:22-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds] 20180417 21:52:51-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180417 22:10:18-!- sevu [~Shiki@p54855F67.dip0.t-ipconnect.de] has joined #wesnoth-dev 20180417 22:54:33-!- TheJJ [~rofl@ipbcc05d72.dynamic.kabel-deutschland.de] has quit [Ping timeout: 256 seconds] 20180417 23:01:51-!- TheJJ [~rofl@ipbcc05d72.dynamic.kabel-deutschland.de] has joined #wesnoth-dev 20180417 23:03:57<+discordbot> ok, now we just need to get that key press bug fixed 20180417 23:04:40<+discordbot> HAVE to 20180417 23:04:54<+discordbot> What is that branch? 20180417 23:05:18<+discordbot> It's identical to master right now. 20180417 23:05:21<+discordbot> yeah, what is that branch... 20180417 23:05:28<+discordbot> mattsc isn't around 20180417 23:05:50<+discordbot> mattsc: Did you by any chance try to run wmllint and mess up the command line in the middle of a git invocation? 20180417 23:06:21<+discordbot> @Vultraz yes I know, but he unlike you has always read the IRC logs. 20180417 23:10:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180417 23:10:13<+discordbot> and someone needs to take screenshots! 20180417 23:10:20<+discordbot> Would it be possible that I could get rights to change topic and pin messages for the german channel? I'm trying to organize translating of the german version (since somehow nobody else did 😦 ) 20180417 23:10:47<+discordbot> @sevu translating the german version of what? 20180417 23:10:56<+discordbot> of wesnoth 20180417 23:10:59<+discordbot> for 1.14 20180417 23:11:01<+discordbot> Did you talk with Ivanovic to get control of the team? 20180417 23:11:38<+discordbot> you should have Manage Channel permissions for #german in any case now 20180417 23:12:32<+discordbot> No, not yet. And to be honest, I don't really want to take over the translation maintainer role 20180417 23:15:31-!- grzywacz [~karol@89-70-226-147.dynamic.chello.pl] has quit [Ping timeout: 256 seconds] 20180417 23:17:09<+discordbot> My curent state is I wrote with the former maintainer, and see that nobody worked on the translation yet. I know that there is someone who had interresst in translating about 1-2 years (though I don't know who). As for ivanovic, what's the best mail to contact him, by mail? 20180417 23:17:49<+discordbot> Yes. 20180417 23:18:02<+discordbot> https://wiki.wesnoth.org/WesnothTranslationsHowTo 20180417 23:20:14<+discordbot> is he in irc sometimes? I mean, I see him, but don't remember him writing 20180417 23:21:25-!- travis-ci [~travis-ci@ec2-54-92-178-164.compute-1.amazonaws.com] has joined #wesnoth-dev 20180417 23:21:26< travis-ci> wesnoth/wesnoth#17682 (mllint - fc3ca7a : Jyrki Vesterinen): The build failed. 20180417 23:21:26< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/367904986 20180417 23:21:26-!- travis-ci [~travis-ci@ec2-54-92-178-164.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180417 23:23:06<+discordbot> He's busy, use emails if you don't want your messages to fall through the cracks. 20180417 23:23:19<+discordbot> okay 20180417 23:23:27-!- sevu [~Shiki@p54855F67.dip0.t-ipconnect.de] has quit [Quit: Verlassend] 20180417 23:25:41<+discordbot> Thanks Vultraz. Would it be possible to set up to allow me pining messages? Speaking about thet pin button at the top right. That would be useful to link to the messages explaining how translation stuff works 20180417 23:26:48<+discordbot> you now have Manage Messages 20180417 23:27:49<+discordbot> Thanks. One more thing, the deadline for translations is the tagging date, or before? 20180417 23:29:37<+discordbot> the tagging date 20180417 23:29:52<+discordbot> makes no sense to make it earlier 20180417 23:29:57<+discordbot> okay 20180417 23:33:35<+discordbot> @Vultraz I may have the time tonight to make another shot at the IME composition. It should be relatively simple, after all, to copy over the SDL input tutorial code. Unless we complicated it. 😄 20180417 23:35:52< irker865> wesnoth: Charles Dang wesnoth:master a7e1ff85ed10 / src/lexical_cast.hpp: Fixup c57a175fee701b4d19c09653a5c9445b778d139e https://github.com/wesnoth/wesnoth/commit/a7e1ff85ed10fa56512583648727155a54a2b0cd 20180417 23:38:41-!- gfgt [~androirc@134.76.63.8] has joined #wesnoth-dev 20180417 23:42:09-!- gfg [~androirc@134.76.63.8] has quit [Ping timeout: 256 seconds] 20180417 23:43:34-!- TheJJ [~rofl@ipbcc05d72.dynamic.kabel-deutschland.de] has quit [Ping timeout: 256 seconds] 20180417 23:43:36-!- gfgt [~androirc@134.76.63.8] has quit [Ping timeout: 256 seconds] 20180417 23:52:01<+discordbot> celmin around? 20180417 23:55:24< celmin|sleep_stu> Nice timing. 20180417 23:56:16<+discordbot> What do you think about commit messages that reference ALL of commit hash, issue number and issue subject? Commit hashes can change after force-push, and the reason behind the commit gets completely lost. (this is partially true even if the hash didn't change). @Vultraz 20180417 23:56:42<+discordbot> @sinda we don't force-push to master 20180417 23:57:40<+discordbot> Well, you don't know what happens to the hashes in future. 20180417 23:57:47<+discordbot> celmin: thought about the loading screen. What if we used an std::future for the worker result, spawned the worker with std::async, then used future::wait_for(0) to test its validity? 20180417 23:57:55<+discordbot> Wesnoth might migrate to hg or whatever, for example. 20180417 23:58:09<+discordbot> @sinda I don't get what you're getting at 20180417 23:58:13< celmin|sleep_stu> Yeah I don't know how you can confuse auto lambdas with constexpr. :P 20180417 23:58:31<+discordbot> celmin: not thinking sometimes 20180417 23:58:52< celmin|sleep_stu> @Vultraz — I dunno. I have a general basic understanding of futures and promises and such but haven't really used them for anything real. 20180417 23:59:15<+discordbot> @sinda we already reference issue numbers in commit messages. Including the full hash and subject seems like overkill 20180417 23:59:43< celmin|sleep_stu> @sinda — IMO if you're making fixup commits you should use the command-line and run "git commit --fixup commit_to_fixup", though it's also handy to add the hash so github will link to it. --- Log closed Wed Apr 18 00:00:06 2018