--- Log opened Fri May 11 00:00:42 2018 20180511 00:09:03< irker328> wesnoth: Charles Dang wesnoth:master 497d58df6f9e / src/filesystem_boost.cpp: Convert use of deprecated SHGetFolderPathW to SHGetKnownFolderPath https://github.com/wesnoth/wesnoth/commit/497d58df6f9e17c58aea518ef8ede2c4e19393a8 20180511 00:09:06< irker328> wesnoth: Charles Dang wesnoth:master 2a585118d8b6 / / (10 files in 5 dirs): Bump min required Windows version to 7 https://github.com/wesnoth/wesnoth/commit/2a585118d8b6c4b37d0ff9446a72ca20419ff7f7 20180511 00:10:38< celticminstrel> As long as you never bump it past 7 I'll be fine. 20180511 00:10:57<+discordbot> 7 should be find since VS 2017 supports 7 20180511 00:12:24<+discordbot> You don't need to explicitly call the W version. 20180511 00:12:57< celticminstrel> Calling the W version means you can't compile as non-Unicode or some such. 20180511 00:13:15< celticminstrel> Which IMO is a good thing, but YMMV. 20180511 00:13:17<+discordbot> Yeah, but we're never going to want to call the ANSI version. 20180511 00:13:19<+discordbot> No. 20180511 00:13:34<+discordbot> Oh, never mind, I read that wrong. 20180511 00:14:10<+discordbot> Although I just realized that it's not guaranteed that UNICODE is defined for that file. 20180511 00:14:19<+discordbot> (Unlike in src/desktop/open.cpp.) 20180511 00:14:44< celticminstrel> Isn't that normally defined in project configuration? 20180511 00:15:04<+discordbot> ah, but you reminded me I forgot the CoTaskMemFree call. 20180511 00:16:18<+discordbot> What? 20180511 00:16:39< irker328> wesnoth: Charles Dang wesnoth:master 41b436abd33b / src/filesystem_boost.cpp: Fixup 497d58d (forgot to free the doc path) https://github.com/wesnoth/wesnoth/commit/41b436abd33bb3cf8f72d63c34f54e4bfa27f423 20180511 00:16:40<+discordbot> The docs say I need it 20180511 00:17:01<+discordbot> Oh I see, I was looking at the documentation for the previous function. 20180511 00:19:02<+discordbot> It seems like only the Unicode version of the function exists anyway. 20180511 00:19:32<+discordbot> Since the documentation says the fourth parameter is a PWSTR rather than an PTSTR. 20180511 00:44:14< EliDupree> So I've got a table that put_unit is telling me isn't a valid WML table (but of course, it doesn't tell me what's invalid about it). I'm trying to write myself some better functions for debugging this. Is there any lua function that can just tell me whether a WML table is valid without trying to do something with it? 20180511 00:45:15< EliDupree> In particular, I already wrote a function to identify the exact position in the table where an invalid value occurs, but it isn't detecting the problem in this particular table, so there must be an additional way of being invalid that I consider – but I don't know what that way is 20180511 00:46:06< EliDupree> And I also have a function to debug-output the entire contents of the table to the command line, but that isn't working for the previously mentioned reason of the error log not displaying at all on Windows (and I can only work on Windows at the moment). And it's too big to fit in the in-game log. 20180511 00:47:40<+discordbot> that'd be better in #modding or the Lua Labs forum 20180511 00:48:09< Ravana_> I recall the channel is not connected still 20180511 00:48:20< EliDupree> I'm on IRC, I don't see a modding channel 20180511 00:48:32< EliDupree> I suppose I could easily join the discord though 20180511 00:49:01<+discordbot> ah 20180511 00:49:03<+discordbot> right 20180511 00:52:21< celticminstrel> What's the table? 20180511 00:52:38< celticminstrel> EliDupree: ^ 20180511 00:52:52< EliDupree> A unit. 20180511 00:52:54< celticminstrel> We should definitely add that actually... 20180511 00:53:05< celticminstrel> A wml.is_valid() function or something similar. 20180511 00:53:13< celticminstrel> The table is a stored unit? 20180511 00:53:24< celticminstrel> There shouldn't be anything invalid if you got the WML table from the engine... 20180511 00:53:28< EliDupree> Ideally, whenever the game complains of an invalid WML table, it should tell the user which field of the table makes it invalid 20180511 00:53:52< EliDupree> I dump the unit's __cfg, modify it a bunch, and try to put it back 20180511 00:54:45< celticminstrel> Probably need to see code to figure out what's going on here... either that or a dump of the table. 20180511 00:55:07< EliDupree> Well, I would be happy to show you a dump of the table provided that the features that exist specifically for the purpose of being able to dump data would work 20180511 00:55:20< EliDupree> The code is much too complex for me to show you usefully 20180511 00:55:36< celticminstrel> I've definitely seen a function for dumping a WML table but I don't think it was in core... 20180511 00:56:00< celticminstrel> Still, print() might be good enough. 20180511 00:56:24< EliDupree> EoHS already incorporates a lua library for representing an arbitrary table as a string. I use this library to dump the table as a string and output it to… Guess what, wesnoth.log 20180511 00:56:28< celticminstrel> Or wait, I guess that's not the one... 20180511 00:56:46< celticminstrel> Basically the function that prints the output of commands execute in the Lua console. 20180511 00:57:12< celticminstrel> I think it's ilua._pretty_print. 20180511 00:57:34< celticminstrel> ^executed 20180511 00:57:44< EliDupree> I suppose another possible approach would be to write a string in a WML variable, save the game, and examine the save file with a text editor 20180511 00:57:53< Ravana_> core has wesnoth.debug 20180511 00:57:59< celticminstrel> Oh yeah. 20180511 00:58:05< celticminstrel> But that won't actually help here, Ravana_. 20180511 00:58:18< celticminstrel> Because that requires it to be a valid WML table already. 20180511 00:58:37< celticminstrel> You need something that can print out an arbitrary Lua table, which ilua._pretty_print should be able to... 20180511 00:59:06< celticminstrel> I have no idea how that saved game approach would help. 20180511 00:59:30< EliDupree> I am already able to represent arbitrary tables as strings. The problem is viewing the string. 20180511 00:59:44< celticminstrel> Oh. 20180511 00:59:50< celticminstrel> The Lua console isn't good enough? 20180511 01:00:13< EliDupree> That is correct. A unit is much too large to display in the chat messages. 20180511 01:00:27< celticminstrel> Um, that's not the Lua console. 20180511 01:00:31< EliDupree> And even if it was, I couldn't copy the text from there in order to show you. 20180511 01:00:36< celticminstrel> Try pressing tilde. 20180511 01:00:50< celticminstrel> Or if that fails, :inspect and click "Lua console". 20180511 01:00:52< Ravana_> I have written simple GUI for exploring Lua table during scenario, but that would only help if you know what part of table is interesting 20180511 01:01:07< celticminstrel> Pretty sure it has a button to copy the output, too. 20180511 01:01:19< celticminstrel> Though that copies the full output, but you can then trim it down to the bit of interest. 20180511 01:01:35< EliDupree> Is there a way to invoke this lua console in the middle of other function calls? 20180511 01:01:48< celticminstrel> Yes, but it won't have access to any local variables. 20180511 01:01:53< celticminstrel> wesnoth.show_lua_console() IIRC 20180511 01:02:27< celticminstrel> (I want to give it that access, but it's hard.) 20180511 01:03:01< EliDupree> As I don't have the latest wesnoth installed on the computer I'm currently chatting from, I can't examine it myself, but I will keep that in mind as a possible debugging technique 20180511 01:03:30< celticminstrel> You could probably ilua._pretty_print(the_value) and then open the console and find it printed. 20180511 01:03:33< EliDupree> I suppose I would have to make a global variable in which to insert the data I wanted to examine 20180511 01:03:37< celticminstrel> Or that. 20180511 01:05:16< EliDupree> The wiki doesn't mention a wesnoth show_lua_console() 20180511 01:05:45< celticminstrel> It hasn't been documented yet. 20180511 01:06:38-!- gfgtdf_ [~chatzilla@x4e32b1f9.dyn.telefonica.de] has joined #wesnoth-dev 20180511 01:09:49-!- gfgtdf [~chatzilla@x4e363a75.dyn.telefonica.de] has quit [Ping timeout: 260 seconds] 20180511 01:10:03-!- gfgtdf_ is now known as gfgtdf 20180511 01:15:56< irker328> wesnoth: Charles Dang wesnoth:master b89b89abeaf4 / src/filesystem_boost.cpp: Only redefine VOLUME_NAME_NONE if it's not previously defined https://github.com/wesnoth/wesnoth/commit/b89b89abeaf48c825bc2b4b22a035ada3293f4c3 20180511 01:15:59< irker328> wesnoth: David white wesnoth:master 388622844781 / src/ (actions/attack.cpp random.hpp random_synced.cpp random_synced.hpp): added use_prng preference which adds a new experimental pseudo-RNG for casual ca https://github.com/wesnoth/wesnoth/commit/388622844781afbbb741e0d03827060dbd3dad2e 20180511 01:16:01< irker328> wesnoth: Charles Dang wesnoth:master f105fa20361a / src/filesystem_boost.cpp: Filesystem/Boost: formatting cleanup https://github.com/wesnoth/wesnoth/commit/f105fa20361afd48ad80eac01e7c2971b82d1097 20180511 01:16:04< irker328> wesnoth: Charles Dang wesnoth:master 32111ae5e9f0 / src/filesystem_boost.cpp: Filesystem/Boost: made use of std::make_unique https://github.com/wesnoth/wesnoth/commit/32111ae5e9f05cd2e8ce708eed574ce0560c299e 20180511 01:16:07< irker328> wesnoth: Charles Dang wesnoth:master c643b765dd78 / src/filesystem_boost.cpp: Filesystem/Boost: range-for https://github.com/wesnoth/wesnoth/commit/c643b765dd78d32983658584a959447e6e96da62 20180511 01:16:10< irker328> wesnoth: Charles Dang wesnoth:master 0f9a0fac5eb4 / src/filesystem_boost.cpp: Filesystem/Boost: don't import boost::fileystem::path class to global namespace https://github.com/wesnoth/wesnoth/commit/0f9a0fac5eb49c62f99e748842ff1984894c2de4 20180511 01:16:21< irker328> wesnoth: Charles Dang wesnoth:1.14 b2bce0dca195 / src/filesystem_boost.cpp: Only redefine VOLUME_NAME_NONE if it's not previously defined https://github.com/wesnoth/wesnoth/commit/b2bce0dca1952940d0c0514569f01fb7de59866c 20180511 01:16:24< irker328> wesnoth: Charles Dang wesnoth:1.14 f40b58c156da / src/filesystem_boost.cpp: Filesystem/Boost: formatting cleanup https://github.com/wesnoth/wesnoth/commit/f40b58c156dab0afa093920bdd3f6aafcba6ee78 20180511 01:16:28< irker328> wesnoth: Charles Dang wesnoth:1.14 051f9232d8b7 / src/filesystem_boost.cpp: Filesystem/Boost: range-for https://github.com/wesnoth/wesnoth/commit/051f9232d8b7ca7f41a547ed467365f479b2ff8e 20180511 01:16:30< irker328> wesnoth: Charles Dang wesnoth:1.14 1a5ef4dab46d / src/filesystem_boost.cpp: Filesystem/Boost: don't import boost::fileystem::path class to global namespace https://github.com/wesnoth/wesnoth/commit/1a5ef4dab46d22eee4a6e1fec92bea74d7aba92b 20180511 01:16:35<+discordbot> (normally I wouldn't backport formatting commits but in this case not doing so would make it impossible to port between branches if we touched this file) 20180511 01:19:04<+discordbot> ... why. 20180511 01:19:34<+discordbot> why what? 20180511 01:19:45<+discordbot> Ugh. 20180511 01:19:49<+discordbot> Just... never mind. 20180511 01:20:02<+discordbot> i usually do a formatting cleanup if I work with a file. 20180511 01:20:24<+discordbot> You need to work on that terrible habit of yours. 20180511 01:23:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180511 01:51:48< EliDupree> Well, I managed to extract my string representation of the unit. Still really big to look at of course 20180511 01:51:49< EliDupree> https://pastebin.com/jHRyJPsZ 20180511 01:52:33< EliDupree> So far, the only unusual thing I notice is that some of the tables have metatables… Could that be why it's failing and 1.14.1 when it wasn't failing in earlier versions? 20180511 01:54:55-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has quit [Read error: Connection reset by peer] 20180511 01:55:55< EliDupree> (Earlier = wesnoth 1.13.10) 20180511 02:26:50< celticminstrel> Not sure why there are metatables there... 20180511 02:29:21< celticminstrel> So, I'm not seeing anything that could cause an issue, but it's so big that I could've easily missed something. Maybe break it into chunks? 20180511 02:29:37< celticminstrel> For example, try using wml.tostring() on various parts of it and see where it fails. 20180511 02:31:02< celticminstrel> Or alternatively, deleting parts and checking if it works without that part. 20180511 02:35:09< celticminstrel> https://steamcommunity.com/app/599390/discussions/0/1696046976476521292/ 20180511 02:35:12< celticminstrel> What the heck is that. 20180511 02:36:02< celticminstrel> XD https://steamcommunity.com/app/599390/discussions/0/1696046976475430833/ 20180511 02:38:06<+discordbot> I can't find the option for /Zc:__cplusplus.... 20180511 02:40:00< celticminstrel> Can we pin a thread on Steam saying "Stop asking for workshop support"? 20180511 02:40:14< EliDupree> celticminstrel: The metatables are something I added to make those tables read-only for unrelated reasons. And then didn't bother to remove them when including them in the final unit table 20180511 02:40:30< celticminstrel> Being read-only shouldn't cause any problems AFAIK. 20180511 02:40:39< celticminstrel> Chances are the C++ is using rawget in any case. 20180511 02:40:45< celticminstrel> And it's not modifying anything even with rawset. 20180511 02:40:53<+discordbot> celticminstrel: If you can phrase it in a way that's informative enough for the general public, then yes. 20180511 02:40:59< EliDupree> hmm 20180511 02:41:32< celticminstrel> IOW what you're saying is, if I make a post about it and it seems good, you'll pin it? 20180511 02:41:57<+discordbot> Or @Pentarctagon. 20180511 02:42:15< celticminstrel> Ah that's probably better, indeed. 20180511 02:42:30<+discordbot> rebuilds boost 20180511 02:43:08< irker328> wesnoth/wesnoth:master Charles Dang 0f9a0fac5e Filesystem/Boost: don't import boost::fi AppVeyor: vs2015/Debug Failed 20180511 02:43:09< irker328> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3245 20180511 02:44:57<+discordbot> really, did they forget to add this or something.. 20180511 02:46:28< celticminstrel> ? 20180511 02:46:48< celticminstrel> ...heh, EliDupree: https://steamcommunity.com/app/599390/discussions/0/2828702372993981703/ 20180511 02:47:29< EliDupree> :) 20180511 02:47:51<+discordbot> celmin: VS now correctly sets __cplusplus if you have the /Zc:__cplusplus option set. But I can't find anywhere to set that option 😐 20180511 02:47:52< celticminstrel> Someone is impatient. 20180511 02:48:14< celticminstrel> @Vultraz If there's no UI for it you can put it in "other options". 20180511 02:48:29< EliDupree> Yeah, I'm working on it but unfortunately I also have cubital tunnel 20180511 02:48:32< celticminstrel> Though I don't think that should be necessary? 20180511 02:48:39<+discordbot> I tried putting it under command line 20180511 02:48:41< celticminstrel> Is that any relation to carpal tunnel? 20180511 02:48:47<+discordbot> but it doesn't appear in the evaluated options list 20180511 02:48:53< EliDupree> Vaguely, it's a different nerve and the problem is in the elbow 20180511 02:49:03< celticminstrel> Huh. 20180511 02:49:53< EliDupree> Anyway, I'm probably getting surgery in a few months that will fix it, but in the meantime, I can't do very much programming. I'm actually working with someone else over screen sharing to try to fix EoHS 20180511 02:50:02< celticminstrel> o.o 20180511 02:51:15<+discordbot> maybe if i just stick it in the box it will work 20180511 02:52:00< celticminstrel> I don't get why you even need this, pretty sure VS has always set __cplusplus? 20180511 02:52:20<+discordbot> no, it was always set to 199711L 20180511 02:52:43< celticminstrel> Ah, okay, so it was set and worked for the common use-case but not for the less-common one. 20180511 02:52:44<+discordbot> the new /Zc:__cplusplus sets it properly like other compilers 20180511 02:53:16<+discordbot> I'm trying to get a c++17 build working here 20180511 02:53:28< celticminstrel> Eh... 20180511 02:54:06< celticminstrel> BTW, what happens if you set that on MSVC 2015? 20180511 02:54:29<+discordbot> It's a new option in 15.7 20180511 02:54:39< celticminstrel> I have no idea what 15.7 means. 20180511 02:54:53<+discordbot> latest VS 2017 20180511 02:55:12< celticminstrel> So probably not something you should be using in Wesnoth. 20180511 02:55:28< celticminstrel> Though that partly depends on how cl.exe deals with unknown arguments. 20180511 02:55:46<+discordbot> If it doesn't work for some reason I need to fix the HAVE_CXX17 check 20180511 02:55:53<+discordbot> right now it checks __cplusplus 20180511 02:56:24< celticminstrel> Well, that's easy though, just check the MSVC version instead if _MSC_VER is defined. 20180511 02:56:40< celticminstrel> But my point is it needs to work on 2015. 20180511 02:57:10<+discordbot> We're probably going to make 2017 the minimum version 20180511 02:57:34<+discordbot> now... ok, apparently I just built 64 bit boost too? 20180511 02:59:33<+discordbot> only need the 32 ones... 20180511 03:04:29<+discordbot> I think I may have done this wrong 🤔 20180511 03:07:05<+discordbot> that is, not sure if ./b2 takes cxxflags=-std=c++17 or just -std=c++17 20180511 03:30:15<+discordbot> seems to be working 20180511 03:30:23<+discordbot> last time I tried I got a million errors about auto_ptr 20180511 03:30:25<+discordbot> now those are gone 20180511 03:30:27<+discordbot> just some warnings 20180511 03:31:21<+discordbot> Considering that std::auto_ptr was deprecated in C++11 and it's been removed in C++17... 20180511 03:31:44<+discordbot> Indeed. 20180511 03:31:53<+discordbot> Which means I guess I build boost properly 20180511 03:32:03<+discordbot> Or you have the correct version of Boost. 20180511 03:32:17<+discordbot> Also possible 20180511 03:32:31<+discordbot> I didn't try building with the version wedge built for the external repo 20180511 03:32:33<+discordbot> (of 1.67) 20180511 03:34:47<+discordbot> oh hell, unresolved externals... 20180511 03:40:14<+discordbot> also I had to copy phoenix, fusion, and spirit over verbatim since our build instructions didn't cover them entirely 20180511 03:44:45< celticminstrel> But at least those are header-only IIRC 20180511 03:45:14< celticminstrel> The only libs you actually need to build are filesystem and system, and I guess thread (maybe chrono if that's a lib). 20180511 03:45:35< celticminstrel> Or wait, we switched to std::thread didn't we? 20180511 03:45:40< celticminstrel> So only filesystem and system? 20180511 03:52:55<+discordbot> thread still seems to be needed by locale 20180511 03:53:34<+discordbot> c:\users\exodi\documents\wesnoth\src\actions\create.cpp 685 20180511 03:53:36<+discordbot> 🤔 20180511 03:53:47<+discordbot> Warning C4834 discarding return value of function with 'nodiscard' attribute wesnoth 20180511 03:54:56< celticminstrel> Ah. 20180511 03:55:00<+discordbot> they all seem to be std::get 20180511 03:55:01< celticminstrel> I forgot about locale somehow. 20180511 03:55:10< celticminstrel> std::get as in tuple? 20180511 03:55:16<+discordbot> mhm 20180511 03:55:25< celticminstrel> Oh I guess variant has that too, though IIRC that's not in the standard yet... 20180511 03:56:00<+discordbot> std::variant is C++17 20180511 03:56:01< celticminstrel> I'm not entirely sure why it's nodiscard, but I guess it does make little sense to call std::get if you're not going to use the resuly. 20180511 03:56:04< celticminstrel> ^result 20180511 03:56:13< celticminstrel> Oh, so does std::get work on variant too? 20180511 03:56:32< celticminstrel> Though technically it'd be a different function, std::get instead of std::get. 20180511 03:56:35<+discordbot> yes 20180511 03:56:42<+discordbot> http://en.cppreference.com/w/cpp/utility/variant/get 20180511 03:56:47< celticminstrel> But anyway that's beside the point, where are you getting this error? 20180511 03:57:18<+discordbot> actions/create.cpp 20180511 03:57:19<+discordbot> it's a warning 20180511 03:58:16< celticminstrel> Geh. 20180511 03:58:20< celticminstrel> Line number? 20180511 03:58:36<+discordbot> 685 is one 20180511 03:59:01< celticminstrel> Hmm. 20180511 03:59:12< celticminstrel> Okay I think I'd classify this as a compiler bug. 20180511 03:59:35<+discordbot> src\actions\create.cpp(656): warning C4834: discarding return value of function with 'nodiscard' attribute src\actions\create.cpp(677): warning C4834: discarding return value of function with 'nodiscard' attribute src\actions\create.cpp(685): warning C4834: discarding return value of function with 'nodiscard' attribute src\actions\create.cpp(691): warning C4834: discarding return value of function with 'nodiscard' attribute 20180511 03:59:35<+discordbot> src\actions\create.cpp(696): warning C4834: discarding return value of function with 'nodiscard' attribute src\actions\create.cpp(698): warning C4834: discarding return value of function with 'nodiscard' attribute 20180511 04:00:10< celticminstrel> Though... 20180511 04:00:11<+discordbot> iostreams link still failing on wesnothd and campaignd 20180511 04:00:13<+discordbot> 😦 20180511 04:00:38< celticminstrel> Okay yeah, I'd call that a compiler bug. 20180511 04:00:47<+discordbot> There is no sound or music on the iPad version of 1.14.1 20180511 04:00:52< celticminstrel> Either that or the library is inappropriately marking it nodiscard. 20180511 04:01:02<+discordbot> guess we should silence C4834 then 20180511 04:01:11<+discordbot> @SageSeer speak to @sinda 20180511 04:01:12< celticminstrel> But std::get returns a reference, so assigning to it should probably be counted as not discarding it. 20180511 04:01:23<+discordbot> Ok will do 20180511 04:01:34<+discordbot> in #ios 20180511 04:02:00<+discordbot> On the forum? 20180511 04:02:09<+discordbot> no in the #ios channel here 20180511 04:02:19<+discordbot> oh wait 20180511 04:02:21<+discordbot> that'snot public 20180511 04:02:23<+discordbot> ... 20180511 04:02:24<+discordbot> 🤔 20180511 04:02:27<+discordbot> I forgot 20180511 04:02:32<+discordbot> I don’t see an #ios 20180511 04:02:36<+discordbot> Yeah, ignore that. 20180511 04:02:38<+discordbot> ...we should have a public version of that 20180511 04:02:54<+discordbot> @SageSeer DM or here is fine. Sorry. SPacing out. 20180511 04:03:57<+discordbot> I already have dm set with sinda 20180511 04:04:23<+discordbot> AGH 20180511 04:04:24<+discordbot> Thanks I’ll mention with dm or forum. 20180511 04:04:31< celticminstrel> People who label issues (eg @sevu, wedge009), please make sure to always add at least one purple tag plus either "bug" or "enhancement" to all issues (unless they're something really unusual like the "please add to F-Droid" one). 20180511 04:04:32<+discordbot> I fucked up 20180511 04:04:43<+discordbot> no wonder the link is failing 20180511 04:05:10<+discordbot> the instructions in the README refer to zlib-1.2.8 20180511 04:05:16<+discordbot> I copied that verbatim 20180511 04:05:20<+discordbot> my dir is zlib-1.2.11 20180511 04:05:24<+discordbot> (╯°□°）╯︵ ┻━┻ 20180511 04:06:28<+discordbot> rebuilds iostreams 20180511 04:07:22-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: celticminstrel] 20180511 04:13:21<+discordbot> so far I've needed to define: 20180511 04:13:23<+discordbot> _SILENCE_CXX17_ITERATOR_BASE_CLASS_DEPRECATION_WARNING _SILENCE_CXX17_ALLOCATOR_VOID_DEPRECATION_WARNING _SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING 20180511 04:18:19<+discordbot> Ok sent a post in the forum and did a dm to sinda 20180511 04:32:53<+discordbot> ok, this is weird.. 20180511 04:34:32<+discordbot> Error C2059 syntax error: '<' wesnoth c:\users\exodi\documents\wesnoth\src\gui\core\event\dispatcher_private.hpp 291 CL 20180511 04:34:38<+discordbot> :bowman: 20180511 04:35:44<+discordbot> must be a compiler bug 20180511 04:43:05<+discordbot> wonder if i should report it 20180511 04:45:50<+discordbot> hmmm 20180511 04:46:47<+discordbot> let's see... 20180511 04:48:11<+discordbot> if i remove the function body it passes 20180511 04:48:19-!- DeFender [~DeFender1@89-138-79-9.bb.netvision.net.il] has quit [Quit: I'm not back now.] 20180511 04:48:22<+discordbot> HUH 20180511 04:48:57<+discordbot> dispatcher::signal_type& signal = dispatcher_implementation::event_signal(*ritor_widget.first, ritor_widget.second); fails 20180511 04:49:17<+discordbot> auto& signal = dispatcher_implementation::event_signal(*ritor_widget.first, ritor_widget.second); 20180511 04:49:18<+discordbot> works 20180511 04:50:00<+discordbot> definitely looks like a compiler bug 20180511 04:57:44<+discordbot> confirmed the /Zc:__cplusplus option does work 20180511 04:58:01<+discordbot> #if __cplusplus >= 201703L defines HAVE_CXX17 properly 20180511 04:59:45<+discordbot> ok, here's some c++17 deprecation warnings for our code 20180511 05:02:00<+discordbot> whoot! 20180511 05:02:46<+discordbot> My latest master build with c++17 on the latest VS with the latest boost and the latest Win 10 SDK works \o/ 20180511 05:08:09-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180511 05:11:31< irker328> wesnoth: Charles Dang wesnoth:master 1c575f59fa16 / src/gui/core/event/dispatcher_private.hpp: Work around some weird compiler bug with VS using C++17 https://github.com/wesnoth/wesnoth/commit/1c575f59fa16029247c6d05c5e5f7b74cafdc26e 20180511 05:11:34< irker328> wesnoth: Charles Dang wesnoth:master f279ad5fc0f8 / src/ (movetype.cpp whiteboard/manager.cpp): Whiteboard: avoid the use of a deprecated C++17 function https://github.com/wesnoth/wesnoth/commit/f279ad5fc0f83ee946ab75049994fdbbd0ca18d5 20180511 05:33:12-!- gallaecio [~quassel@188.79.96.255] has quit [Remote host closed the connection] 20180511 05:34:35-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180511 05:36:13< wedge009> Vultraz: What was wrong before? 20180511 05:37:05< wedge009> celticminstrel: Pretty much what I do already, but will keep that in mind. 20180511 05:37:59<+discordbot> what? 20180511 05:38:06<+discordbot> what was wrong what when where? 20180511 05:38:16< wedge009> My latest master build with c++17 on the latest VS with the latest boost and the latest Win 10 SDK works \o/ 20180511 05:38:33<+discordbot> was having build problems 20180511 05:38:42< wedge009> Does c++17 need to be enabled explicitly? 20180511 05:38:47<+discordbot> yes 20180511 05:38:51< wedge009> Ah, okay. 20180511 05:38:57<+discordbot> and you need to rebuild boost 20180511 05:39:10<+discordbot> (at least, you did the last time I tried with... 1.66 I think) 20180511 05:39:37< wedge009> Well, boost uses whatever platform's compiler you want to use, so I presume there's some extra switches needed there too. 20180511 05:40:09<+discordbot> I build with -std=c++17 added to .\b2 20180511 05:40:17-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180511 05:40:55< wedge009> Oh that's right, I think I experimented with the std parameter a while back, there were a lot of errors but then MSVC support was still lacking. 20180511 05:41:21<+discordbot> the new VS 15.7 release has full C++ standard compliance 20180511 05:41:23<+discordbot> including c++17 20180511 05:41:34< wedge009> Yeah, I saw you talking about that... maybe yesterday? 20180511 05:41:43< wedge009> I was wondering why it was such a big update a few days ago. 20180511 05:47:17<+discordbot> indeed 20180511 05:47:19<+discordbot> 1.5 GB 20180511 05:48:37-!- travis-ci [~travis-ci@ec2-54-160-138-195.compute-1.amazonaws.com] has joined #wesnoth-dev 20180511 05:48:38< travis-ci> Pentarctagon/wesnoth#35 (cmake-fixes - 62b9984 : Pentarctagon): The build passed. 20180511 05:48:39< travis-ci> Build details : https://travis-ci.org/Pentarctagon/wesnoth/builds/377584674 20180511 05:48:39-!- travis-ci [~travis-ci@ec2-54-160-138-195.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180511 06:09:50-!- gallaecio [~quassel@188.79.96.255] has quit [Remote host closed the connection] 20180511 06:14:10-!- DeFender1031 [~DeFender1@89-138-79-9.bb.netvision.net.il] has joined #wesnoth-dev 20180511 06:28:46-!- gallaecio [~quassel@143.red-81-32-24.dynamicip.rima-tde.net] has joined #wesnoth-dev 20180511 06:47:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 06:47:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 07:04:39<+discordbot> so for some weird reason, Microsoft decided NOT to use chrono::system_clock for std::filesystem::file_time_type and instead roll a custom type 😐 Just.... whyyy. 20180511 07:05:15<+discordbot> system_clock satisfies TrivialClock 20180511 07:06:27<+discordbot> I mean, it is standard-compliant since file_time_type is allowed to be implementation-defined... 20180511 07:06:39<+discordbot> but only system_clock has to_time_t 20180511 07:06:40<+discordbot> Maybe Microsoft's file timestamps are more accurate than system_clock? 20180511 07:07:18<+discordbot> What do you need to_time_t for? time_t is a relic from ancient history. 20180511 07:07:50<+discordbot> Oh? 20180511 07:07:53<+discordbot> I did not know this 20180511 07:08:08<+discordbot> alright, then I know what to do 20180511 07:31:51-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009] 20180511 07:39:38<+discordbot> hm 20180511 07:39:46<+discordbot> actually, that's not working really well... 20180511 07:43:10< irker328> wesnoth/wesnoth:master Charles Dang 0f9a0fac5e Filesystem/Boost: don't import boost::fi AppVeyor: 2/4 builds failed 20180511 07:43:11< irker328> Details vs2015/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3245 20180511 07:43:12< irker328> Details vs2017/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-2958 20180511 07:43:19<+discordbot> I'm attempting to use std::filesystem on c++17 (VS only for now), which was actually fairly simple, until I came to last_write_time which returns a file_time_type unlike its boost::filesystem counterpart which returns time_t. Which wouldn't be that much of a problem (I already had a potential fix) exxxxceeepptt for the fact that the value needs to be serialized to a config 😦 Dammit. 20180511 07:44:45-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20180511 07:53:52<+discordbot> If you want to save write time to a config, the way to do it would be: 1. Choose an epoch and subtract it from the write time (returns a std::chrono::duration) 2. duration_cast the duration to a known tick period (say, seconds) 3. Call duration.count() and save the resulting integer 20180511 07:54:32<+discordbot> Also, if we need the time to be compatible with 1.14, then the epoch needs to be January 1, 1970, and the tick period must be seconds. 20180511 07:59:43-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:ad05:fbd5:37fd:89f5] has joined #wesnoth-dev 20180511 08:17:59<+discordbot> let's see... that comes out to something like... `std::chrono::duration_cast(modified.time_since_epoch()).count(); 20180511 08:19:06<+discordbot> Are you sure you can use time_since_epoch()? 20180511 08:19:39<+discordbot> The epoch in std::chrono clocks is unspecified, and different C++ standard library implementations may use different epoches. 20180511 08:20:16<+discordbot> There doesn't seem to be any way to choose an epoch. 20180511 08:20:51<+discordbot> With "choose an epoch", I meant constructing a time_point of any arbitrary time we choose. 20180511 08:20:57<+discordbot> Say, January 1, 2000. 20180511 08:21:09<+discordbot> I see 20180511 08:21:11<+discordbot> 🤔 20180511 08:22:13<+discordbot> oh, blah. I just noticed this codepath leads to functions that must take time_t such as localtime and put_time 20180511 08:22:15<+discordbot> 😦 20180511 08:24:38<+discordbot> Hmm. Unfortunately std::chrono only has time support at this point (no date stuff), so we can't use it to replace those C functions. 😦 20180511 08:24:39<+discordbot> https://stackoverflow.com/a/17223443 20180511 08:25:22<+discordbot> This is one of those times where I really wonder why it seems newer methods make things harder... 20180511 08:25:40<+discordbot> Indeed. 20180511 08:25:58<+discordbot> Don't get me started about the random number generation in C++11. 20180511 08:30:06<+discordbot> The C++20 draft specifies system_clock's epoch must be unix time. How difficult would it have been for the committee to think of that before C++17 and make file_time_type just time_point instead of time_point They seem to have caught on to their screwup because C++20 actually changes it to time_point, and file_clock has to_sys and from_sys functions. Did no one think such things 20180511 08:30:07<+discordbot> would be necessary when implementing the fs library 😐 20180511 08:32:45<+discordbot> Agreed. A file timestamp without any way to convert it to a date (via a known epoch, or conversion to time_t or system_clock) is almost useless. 20180511 08:39:33<+discordbot> I mean, it can technically work if an implementation chooses system_clock for file_time_type (like I said, that's standard-compliant), but we see here, that doesn't always happen.... 20180511 08:44:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 08:44:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 08:48:13<+discordbot> ya know what, this is annoying enough that I'm going to file a bug for it 20180511 08:49:53<+discordbot> Alternatively, the implementation can provide a file_time_type with custom extensions. 20180511 08:50:19<+discordbot> The C++ standard doesn't disallow file_time_type from providing more functions than the standard requires. 20180511 08:50:51<+discordbot> Indeed 20180511 09:05:57< irker328> wesnoth/wesnoth:1.14 Charles Dang 1a5ef4dab4 Filesystem/Boost: don't import boost::fi AppVeyor: All builds passed 20180511 09:19:02< irker328> wesnoth/wesnoth:master Charles Dang f279ad5fc0 Whiteboard: avoid the use of a deprecate AppVeyor: vs2015/Debug Failed 20180511 09:19:03< irker328> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3249 20180511 09:48:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180511 10:20:53< irker328> wesnoth/wesnoth:master Pentarctagon 718ced7a89 Fix FindGLEW being incorrectly named. AppVeyor: vs2015/Debug Failed 20180511 10:20:54< irker328> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3251 20180511 10:26:35-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:ad05:fbd5:37fd:89f5] has quit [Quit: Leaving] 20180511 10:40:21<+discordbot> I filed an issue here: https://developercommunity.visualstudio.com/content/problem/251213/stdfilesystemfile-time-type-does-not-allow-easy-co.html Hope it's the right place. 20180511 10:41:56<+discordbot> Thanks. 😃 20180511 10:43:42<+discordbot> I think it's very unlikely that Microsoft would change file_time_type to system_clock. It's possible that there is already code in production that assumes the type to be that custom type, and changing file_time_type would break backwards compatibility with such code. 20180511 10:44:31<+discordbot> (Such code wouldn't be portable, but nothing blocks developers from creating Visual Studio specific code if they're only targeting Windows anyway.) 20180511 10:45:13<+discordbot> A custom extension to allow conversion to time_t would be more likely. 20180511 10:46:31<+discordbot> Also, Microsoft-specific conversion to time_t is already possible if Microsoft has documented their custom timestamp type, including the epoch and period. 20180511 10:47:48<+discordbot> nods 20180511 10:48:40<+discordbot> We shall see 20180511 10:59:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 10:59:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 11:22:09-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 11:22:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 11:41:55< irker328> wesnoth/wesnoth:1.14 mattsc 2f0ba2ded4 Prevent definition of wml.variables to c AppVeyor: All builds passed 20180511 12:03:04-!- gallaecio [~quassel@143.red-81-32-24.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 20180511 12:05:47-!- travis-ci [~travis-ci@ec2-54-160-138-195.compute-1.amazonaws.com] has joined #wesnoth-dev 20180511 12:05:48< travis-ci> matthiaskrgr/wesnoth#18 (san_path__username - 198a355 : Matthias Krüger): The build failed. 20180511 12:05:48< travis-ci> Build details : https://travis-ci.org/matthiaskrgr/wesnoth/builds/377681227 20180511 12:05:48-!- travis-ci [~travis-ci@ec2-54-160-138-195.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180511 12:08:10< irker328> wesnoth: Severin Glöckner wesnoth:master 8ac1518884b9 / data/campaigns/Under_the_Burning_Suns/utils/abilities.cfg: UtBS: add female variations for all ability names https://github.com/wesnoth/wesnoth/commit/8ac1518884b9e512b3e4ea626f0f9866685344c8 20180511 12:08:12< irker328> wesnoth: Severin Glöckner wesnoth:master 4873f1a41e79 / data/campaigns/Under_the_Burning_Suns/maps/01_The_Morning_After.map: UtBS S1: change terrain code of the death tree hex https://github.com/wesnoth/wesnoth/commit/4873f1a41e791c021a916b6b96ef27ba605978ec 20180511 12:08:47< irker328> wesnoth: Severin Glöckner wesnoth:1.14 bf125851c425 / data/campaigns/Under_the_Burning_Suns/utils/abilities.cfg: UtBS: add female variations for all ability names https://github.com/wesnoth/wesnoth/commit/bf125851c425953c3f5cbbc328f20c51ec7ffe9d 20180511 12:08:49< irker328> wesnoth: Severin Glöckner wesnoth:1.14 6773b95d7072 / data/campaigns/Under_the_Burning_Suns/maps/01_The_Morning_After.map: UtBS S1: change terrain code of the death tree hex https://github.com/wesnoth/wesnoth/commit/6773b95d7072e6da081461792539f792f8642fd9 20180511 12:20:25< zookeeper> what's a death tree... 20180511 12:25:16< matthiaskrgr> a tree without a root? 20180511 12:26:15-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev 20180511 12:26:39< zookeeper> or maybe one from which big branches repeatedly fall on people's heads? 20180511 12:26:42< Rhonda> a lot of nooses hanging from it? 20180511 12:28:01< matthiaskrgr> a tree whose branches were falsely speculatively executed and thus it died 20180511 12:28:36-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180511 12:28:42<+discordbot> a tree whose life cycle has been completely messed p by having two suns in the sky. 20180511 12:34:48< Rhonda> no no, it's not a "dead tree", it's a "death tree" 20180511 12:35:22< Rhonda> A tree that brings death. 20180511 12:35:33< Rhonda> not one that died 20180511 12:36:08< matthiaskrgr> a tree that converts oxygen into carbon monoxyde 24/7 ? 20180511 12:36:23<+discordbot> (i mean, it's actually one that died, but) who knows what mutations it's undergone since the suns went mad 20180511 12:46:11< irker328> wesnoth/wesnoth:1.14 mattsc 11af880a1e Prevent definition of wml.variables to c AppVeyor: All builds passed 20180511 12:53:51-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180511 13:01:34-!- sevu [~Shiki@p548546E5.dip0.t-ipconnect.de] has joined #wesnoth-dev 20180511 13:01:40< irker328> wesnoth/wesnoth:master Severin Glöckner 4873f1a41e UtBS S1: change terrain code of the deat AppVeyor: vs2017/Debug Failed 20180511 13:01:41< irker328> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-2966 20180511 13:02:32< sevu> We could actually add said tree to core.... It's a good image 20180511 13:03:25-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180511 13:05:50< sevu> not to be confused with the "Great Dead Tree", ^Fetd 20180511 13:20:20-!- gallaecio [~quassel@188.79.96.255] has quit [Remote host closed the connection] 20180511 13:42:28-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection] 20180511 14:14:31-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev 20180511 14:19:02< irker328> wesnoth/wesnoth:master Charles Dang f279ad5fc0 Whiteboard: avoid the use of a deprecate AppVeyor: 2/4 builds failed 20180511 14:19:03< irker328> Details vs2015/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3249 20180511 14:19:04< irker328> Details vs2017/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-2962 20180511 14:46:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Quit: going down today for a server move â. peace! â™â™¥ (also wish me luck :x)] 20180511 14:54:48-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180511 15:09:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 15:15:37-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180511 15:20:53< irker328> wesnoth/wesnoth:master Pentarctagon 718ced7a89 Fix FindGLEW being incorrectly named. AppVeyor: 2/4 builds failed 20180511 15:20:54< irker328> Details vs2015/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3251 20180511 15:20:55< irker328> Details vs2017/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-2964 20180511 15:26:39< EliDupree> Thanks to my new testing code, I've found the minimal invalid sub table of my WML table: 20180511 15:26:40< EliDupree> https://pastebin.com/MffdbKrA 20180511 15:28:50< EliDupree> In particular, the contents of the [frame] and [_death_sound_frame] tested as valid. The only unusual thing I see here is a tag that starts with _ 20180511 15:30:47< EliDupree> Conjecture: in some recent version, wesnoth started generating implicit death sound frames from the die_sound attribute, and including them in the unit_type cfg that's exposed to scripts, but scripts also consider tags beginning in _ to be invalid 20180511 15:31:34< EliDupree> So when EoHS copies them and submits them back as a unit animation (in an effect with apply_to = new_animation), it's invalid 20180511 15:35:35< EliDupree> … Oh, hmm, EoHS explicitly creates that tag name 20180511 15:40:17<+discordbot> Your conjecture is right. Tag names can't start with underscores. 20180511 15:40:30< EliDupree> Confirmed: changing the tag name to begin with a letter solved the problem. So my current guess is that wesnoth stopped accepting tag names that begin with underscores, even though that isn't written in the changelog when it should be as a breaking change 20180511 15:40:34<+discordbot> (I wrote the code that rejects such tag names when passed to the Lua API.) 20180511 15:41:09< EliDupree> … What happened in the older versions where it accepted that input? 20180511 15:42:01<+discordbot> Nothing... as long as such WML wasn't saved to the save file. 20180511 15:42:18<+discordbot> However, if it ended up in the save file, then the resulting save couldn't be loaded. 20180511 15:42:25< EliDupree> :o 20180511 15:42:38<+discordbot> I figure it would be very annoying for the player to lose progress that way. 20180511 15:43:25< EliDupree> … Yes, in fact it has been quite annoying on the occasions that EoHS saves couldn't be loaded 20180511 15:44:56<+discordbot> Here's the commit that added the check: https://github.com/wesnoth/wesnoth/commit/52e3772c862e37bc411ef18c19d289f43bea506b#diff-0372c7df0024028834bb3824eca4fde1 20180511 15:45:32<+discordbot> Also, unit tests about allowed tag names: https://github.com/wesnoth/wesnoth/blob/master/data/test/scenarios/test_lua_wml_tagnames.cfg 20180511 15:46:12< EliDupree> nice! 20180511 15:46:43< EliDupree> I always appreciate good unit tests. 20180511 15:47:29-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has joined #wesnoth-dev 20180511 15:49:29< EliDupree> Now, I could have saved an hour or two of testing if there was a clear error message about WHY a WML table is being rejected... 20180511 15:50:06<+discordbot> You can file an enhancement request. 20180511 15:50:23<+discordbot> I think I wouldn't implement it, though. I have too much important stuff to do. 20180511 15:51:21-!- DeFender1031 [~DeFender1@89-138-79-9.bb.netvision.net.il] has quit [Quit: I'm not back now.] 20180511 15:52:32< EliDupree> It's fair if you have *more*-important stuff to do, but I don't appreciate the implication that making things less opaque for add-on developers isn't important 20180511 15:53:08<+discordbot> Sorry, I didn't mean to imply that it's not important. 20180511 15:53:18< EliDupree> :) 20180511 15:53:54< EliDupree> What's the current appropriate place for an enhancement request? The GitHub issues page? 20180511 15:54:09<+discordbot> Yes, that's right. 20180511 15:54:23< EliDupree> Cool, I'll do that then :-) 20180511 16:02:50-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection] 20180511 16:07:57< irker328> wesnoth: mattsc wesnoth:1.14 42bcf049c162 / data/campaigns/Northern_Rebirth/scenarios/02_01_Infested_Caves.cfg: Northern Rebirth S02_01: keep side 8 leader from wandering off too far https://github.com/wesnoth/wesnoth/commit/42bcf049c1627275027dc04c4467b431a6b7efd2 20180511 16:10:18< irker328> wesnoth: mattsc wesnoth:master 9b9aa13a3dba / data/campaigns/Northern_Rebirth/scenarios/02_01_Infested_Caves.cfg: Northern Rebirth S02_01: keep side 8 leader from wandering off too far https://github.com/wesnoth/wesnoth/commit/9b9aa13a3dba40137d8d679fe42d2b679f631ef9 20180511 16:15:17-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 16:15:24-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 16:22:25< irker328> wesnoth: Pentarctagon wesnoth:master f53c6b84cd96 / utils/travis/steps/script.sh: Add osx+cmake support to travis. https://github.com/wesnoth/wesnoth/commit/f53c6b84cd96fa07405ebec699262158fb3311c3 20180511 16:22:27< irker328> wesnoth: Pentarctagon wesnoth:master f5d74cd5ed09 / src/CMakeLists.txt utils/travis/steps/install.sh: Fix building with osx+cmake on travis. https://github.com/wesnoth/wesnoth/commit/f5d74cd5ed0991ac02e3476e44ab1d615a6614a0 20180511 16:22:29< irker328> wesnoth: Pentarctagon wesnoth:master 7a3fb8815bac / src/CMakeLists.txt: Fix missing SDLMain.mm. https://github.com/wesnoth/wesnoth/commit/7a3fb8815bace24a259c2424c1a256ecece2f420 20180511 16:22:31< irker328> wesnoth: Pentarctagon wesnoth:master 8582ce10445f / CMakeLists.txt: Mark OpenGL and GLEW as required in cmake. https://github.com/wesnoth/wesnoth/commit/8582ce10445f1e9d6ecc22621a6265a10c52cdb1 20180511 16:22:33< irker328> wesnoth: Pentarctagon wesnoth:master 34965741bd34 / cmake/ (FindGLEW.cmake FindGLEW.make SelectLibraryConfigurations.cmake): Fix FindGLEW being incorrectly named. https://github.com/wesnoth/wesnoth/commit/34965741bd34da9b0faa905b363b0b8611883a93 20180511 16:23:08< irker328> wesnoth: Pentarctagon wesnoth:1.14 4676889db6ec / src/CMakeLists.txt: Fix missing SDLMain.mm. https://github.com/wesnoth/wesnoth/commit/4676889db6ecc2064c89f419343028665355c984 20180511 16:38:55< mattsc> Blargh. There are also a large number of MESAGE and FOREACH macros left in the test scenarios … 20180511 16:39:17< mattsc> I’ll fix those sometime and push them directly. I don’t think I need to go through a PR for that. 20180511 16:45:11-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180511 16:49:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds] 20180511 16:53:31-!- Choicerer [~bodhidhar@213.152.162.154] has joined #wesnoth-dev 20180511 16:56:55<+discordbot> tags may not begin with underscore. I noticed that on the SyntaxWml page too. When was that restriction added, and why? 20180511 17:03:15<+discordbot> @sapient_n3t Did you see the discussion above? 20180511 17:03:31<+discordbot> I added the restriction on January 17. 20180511 17:04:03<+discordbot> The reason is that the WML parser already rejects such tag names, and if such a tag makes it to a save file, the save can't be loaded. 20180511 17:04:22-!- Choicerer [~bodhidhar@213.152.162.154] has quit [Quit: Leaving.] 20180511 17:21:50-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20180511 17:21:50<+discordbot> @jyrkive well, we've had such tags and variables in the past. I don't recall them causing load issues either. It's not ahuge deal... I was just curious. 20180511 17:21:50-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 256 seconds] 20180511 17:21:50-!- wedge010 is now known as wedge009 20180511 17:21:50-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Quit: No Ping reply in 180 seconds.] 20180511 17:22:41-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev 20180511 17:24:25<+discordbot> maybe the WML parser changed since then, or it was causing save/load issues I never noticed 20180511 17:27:34<+discordbot> See https://github.com/wesnoth/wesnoth/issues/2375 20180511 17:30:47-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180511 17:49:59<+discordbot> Too bad there isn't an Earthy Mine Wall to accompany the new Mine Wall terrain. 20180511 18:01:40< irker328> wesnoth/wesnoth:master Severin Glöckner 4873f1a41e UtBS S1: change terrain code of the deat AppVeyor: 2/4 builds failed 20180511 18:01:41< irker328> Details vs2017/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-2966 20180511 18:01:42< irker328> Details vs2015/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3253 20180511 18:06:40< EliDupree> Ah, now that I fixed my up-front problem, I can once again experience the assertion failure that I got stuck on last time I worked on EoHS. Here's a backtrace: 20180511 18:06:45< EliDupree> https://pastebin.com/j065SfLS 20180511 18:10:48< gfgtdf> and this is 1.14 ? 20180511 18:11:38< EliDupree> 1.14.1 20180511 18:12:54< gfgtdf> this assertion points to use of an invalid enum data, which can uualyl aonyl happen if you eigher access freed memory or when the variable was not properly intilised 20180511 18:13:14< gfgtdf> the later is somhow unlikely from looking at the code, so it's probalby the first 20180511 18:13:28< EliDupree> Yeah, that's about what I was expecting 20180511 18:14:10< EliDupree> It also doesn't happen consistently, another possible sign of memory errors 20180511 18:14:28< gfgtdf> to investigate these type of issues i's useful to use more advanced debugging tools than stacktraces of the assertion failures, matthiaskrgr knows how to do this stuff. 20180511 18:15:15< gfgtdf> but consiering that 1.14 will likely drop temewml its unliekely that somehwo will foind the motivation to work in this unless its somehow easy. 20180511 18:15:38< EliDupree> temewml? 20180511 18:15:55< gfgtdf> themewml* 20180511 18:15:57<+discordbot> 1.14 is not going to drop ThemeWML. 20180511 18:16:06< gfgtdf> i meant 1.15 20180511 18:16:29< EliDupree> Is something else going to replace it? 20180511 18:16:44<+discordbot> Nobody knows yet. 20180511 18:16:47< EliDupree> lol 20180511 18:16:57<+discordbot> If nothing else does, it has to be GUI2 WML. 20180511 18:17:47<+discordbot> Yeah, maybe it sounds like a joke but the truth is that there isn't a single person actively working on that right now and master is broken beyond recognition as a result of a half-baked reengineering of the rendering system. 20180511 18:18:30<+discordbot> The theme UI has to be replaced with something that uses GUI2, that's the only thing that's set in stone for now. 20180511 18:18:57<+discordbot> Whether that means theme definitions will have to be direct GUI2 WML or an abstraction of it hasn't been decided yet. 20180511 18:19:57< EliDupree> Anyhow, my only horse in this race is the lua callbacks for theme items 20180511 18:31:25< irker328> wesnoth: Severin Glöckner wesnoth:master 76134436fc05 / data/campaigns/Northern_Rebirth/scenarios/02_01_Infested_Caves.cfg: NR S2: Avoid Tallin talking to himself https://github.com/wesnoth/wesnoth/commit/76134436fc05507a64a09a1fd3b91e166714f8d9 20180511 18:31:27< irker328> wesnoth: Severin Glöckner wesnoth:master 52d8cef080bc / data/campaigns/Northern_Rebirth/scenarios/02_01_Infested_Caves.cfg: NR S2: refactor objectives https://github.com/wesnoth/wesnoth/commit/52d8cef080bc8045351ee472e7047df2cc516dfa 20180511 18:32:08< irker328> wesnoth: Severin Glöckner wesnoth:1.14 a61223a5510f / data/campaigns/Northern_Rebirth/scenarios/02_01_Infested_Caves.cfg: NR S2: Avoid Tallin talking to himself https://github.com/wesnoth/wesnoth/commit/a61223a5510f33c2fb869a60e1d719bccc69b04e 20180511 18:46:49-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has quit [Ping timeout: 260 seconds] 20180511 18:49:27-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has joined #wesnoth-dev 20180511 18:51:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180511 19:00:13< EliDupree> Well, I ran wesnoth in valgrind, but it's being pretty hard to test because it continues displaying the black "starting game…" screen over everything even after there's a UI you can interact with 20180511 19:01:11< EliDupree> Cool, I managed to get the assertion failure 20180511 19:02:24< EliDupree> Output: https://pastebin.com/eNR8G3Dh 20180511 19:03:11< EliDupree> In particular, here's the first error that was reported in the case of the assertion failure, that wasn't reported when things were working: 20180511 19:03:17< EliDupree> https://pastebin.com/XtmvffgM 20180511 19:04:09<+discordbot> You should fix those TC errors 20180511 19:04:49< EliDupree> ? 20180511 19:05:14< zookeeper> urgh, i'm exhausted enough that everything i said yesterday i'd do today, i'll do... tomorrow! 20180511 19:05:51< EliDupree> Oh, the ones from my output that presumably aren't related to the main problem 20180511 19:05:57<+discordbot> Yes 20180511 19:06:54< EliDupree> Would be nice if that error gave me any information about where the invalid team colors were coming from, so that I could check if/where in my code it was 20180511 19:07:32< EliDupree> As is, my first idea about how to pursue those errors is to write a system for auditing every field of every unit table for invalid values 20180511 19:07:53<+discordbot> Does your code have any ~TC() calls? 20180511 19:08:25< EliDupree> return "~TC("..wesnoth.sides[side].color..","..src_colors..")" 20180511 19:09:06< EliDupree> That's the only one that could be doing it, I have a few others but they are all hardcoded nonnegative integers 20180511 19:11:28< EliDupree> … I guess that must mean that one of the sides has a .color of -1? 20180511 19:12:19< gfgtdf> afaik color was changed to returns strings like "Red". "Blue" etc. 20180511 19:13:10< EliDupree> Oh, is some part of the code trying to parse those strings as numbers, failing, and using -1 as a null value? 20180511 19:13:21< gfgtdf> probably 20180511 19:13:42< EliDupree> In that case, how do I team-color an image for a specific side nowadays? 20180511 19:13:49< gfgtdf> unfort there is afiak no waa to convert string like 'Red' etc to the copprsonsing rgb codes, if you find out how to use side.color in a gui2 "" please let me know 20180511 19:14:44< gfgtdf> i think you can just use ~TC? does tc uses the side number anyway (/instead of te color number) 20180511 19:14:52< gfgtdf> doesn't * 20180511 19:15:04< EliDupree> I guess I can try that 20180511 19:15:46<+discordbot> TC takes side numbers 20180511 19:16:12< EliDupree> Pretty sure when I originally implemented this, it used the default color for that side number rather than the actual color for that side. But that was many many versions ago 20180511 19:16:28<+discordbot> That's no longer the case 20180511 19:16:39<+discordbot> you can use your current code, but you need RC 20180511 19:17:11< EliDupree> yay 20180511 19:17:37<+discordbot> "~RC(" .. src_colors .. ">" .. wesnoth.sides[side].color .. ")" 20180511 19:17:50<+discordbot> OR 20180511 19:18:09<+discordbot> TC with side 20180511 19:22:01<+discordbot> Always a great day when you wake up feeling dizzy as all hell and like you're about to puke all over your laptop 20180511 19:22:19<+discordbot> glorious saturday morning 20180511 19:24:19-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 19:36:43< irker328> wesnoth: Severin Glöckner wesnoth:1.14 ef316bfc0d95 / data/campaigns/Northern_Rebirth/scenarios/02_01_Infested_Caves.cfg: NR S2: remove second endlevel event for hamels death https://github.com/wesnoth/wesnoth/commit/ef316bfc0d953f262a5b2f439ef0ecb2ba36ecab 20180511 19:37:53< irker328> wesnoth: Severin Glöckner wesnoth:master 1f75c5b14d84 / data/campaigns/Northern_Rebirth/scenarios/02_01_Infested_Caves.cfg: NR S2: remove second endlevel event for hamels death https://github.com/wesnoth/wesnoth/commit/1f75c5b14d84bed7afe2944a7a4a0e169ba2b539 20180511 20:02:02-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev 20180511 20:04:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 20:04:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 20:07:21-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180511 20:09:30-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 20:14:32-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has quit [Remote host closed the connection] 20180511 20:14:55-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has joined #wesnoth-dev 20180511 20:26:55-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 20:26:55-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Read error: Connection reset by peer] 20180511 20:27:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 20:51:11< irker328> wesnoth/wesnoth:1.14 Severin Glöckner 6773b95d70 UtBS S1: change terrain code of the deat AppVeyor: All builds passed 20180511 21:05:42-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.8.0/20180430140610]] 20180511 21:15:37-!- louis94 [~~louis94@91.176.171.238] has joined #wesnoth-dev 20180511 21:21:24-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds] 20180511 21:54:28<+discordbot> @loonycyborg https://forums.wesnoth.org/viewtopic.php?f=5&t=47872#p627842 20180511 22:11:19< mattsc> Hmm, travis reports errors for the Lua deprecation fixes PR. It says ‘Errors reported in wml unit tests” which could be caused by what I did. But before that are gui/layout errors. 20180511 22:11:25< mattsc> How do I interpret that? 20180511 22:11:30< mattsc> https://travis-ci.org/wesnoth/wesnoth/jobs/377795362 20180511 22:14:00< mattsc> I guess it’s complaining about a wrong terrain code. 20180511 22:20:01<+discordbot> https://travis-ci.org/wesnoth/wesnoth/jobs/377795362#L597 20180511 22:20:30<+discordbot> mattsc ^ 20180511 22:21:43<+discordbot> everything after "Executing play_test_executor.sh" is unrelated to the WML tests 20180511 22:21:58< mattsc> @Pentarctagon Oh, thanks. That was way higher up than I looked. :P 20180511 22:22:40< mattsc> And that one is likely my fault ... 20180511 22:23:45<+discordbot> yeah, that's actually why I added in the messages of " tests failed!", because there were times I really couldn't tell what was an error I should care about and what wasn't. 20180511 22:25:49< mattsc> Whoops, indeed. I thought I’d caught all those typos … 20180511 22:28:16< mattsc> https://github.com/wesnoth/wesnoth/pull/3079/commits/0661df5315685f5cbfd8bb47a976140d1f86dd02 20180511 22:28:49< mattsc> I guess that’s what we have the unit test for. :) Thanks @Pentarctagon 20180511 22:29:05< mattsc> *tests 20180511 22:29:54-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has joined #wesnoth-dev 20180511 22:30:13-!- TC01 [~quassel@venus.arosser.com] has quit [Remote host closed the connection] 20180511 22:30:42-!- TC01 [~quassel@venus.arosser.com] has joined #wesnoth-dev 20180511 22:31:54< gfgtdf> that sure is a funny test, it has a 1/200 chance to fail, if i understand it correctly 20180511 22:33:19< irker328> wesnoth/wesnoth:1.14 mattsc 20007d139a Lua code: remove deprecated helper.set_w AppVeyor: All builds passed 20180511 22:33:51-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180511 22:37:44< mattsc> gfgtdf: the comments at the beginning of the file say the chance of the test to faile is ~2^-60 20180511 22:37:58-!- louis94 [~~louis94@91.176.171.238] has quit [Remote host closed the connection] 20180511 22:38:02< mattsc> Which is a pretty small number. 20180511 22:38:26-!- louis94 [~~louis94@91.176.171.238] has joined #wesnoth-dev 20180511 22:39:57-!- gallaecio [~quassel@213.99.45.54] has joined #wesnoth-dev 20180511 22:42:17-!- travis-ci [~travis-ci@ec2-54-82-19-209.compute-1.amazonaws.com] has joined #wesnoth-dev 20180511 22:42:18< travis-ci> wesnoth/wesnoth#18091 (master - 3496574 : Pentarctagon): The build has errored. 20180511 22:42:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/377807724 20180511 22:42:19-!- travis-ci [~travis-ci@ec2-54-82-19-209.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180511 22:43:13<+discordbot> hooray network problems 20180511 22:43:31< gfgtdf> right, didnt see that it repeats that test ~60 times 20180511 22:45:28< sevu> mattsc, do you know why with this code the AI does recruit scouts: https://github.com/wesnoth/wesnoth/issues/3090#issuecomment-388453680 20180511 22:48:13< mattsc> @sevu: no. Sounds like there are some other recruitment instructions active as well. 20180511 22:48:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180511 22:50:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180511 22:52:45< sevu> Then it may be the default scouts_per_village thing ... 20180511 22:54:54< mattsc> @sevu actually, yes, I do 20180511 22:55:02< mattsc> No, it’s not, it’s this: 20180511 22:55:36< mattsc> https://github.com/wesnoth/wesnoth/blob/master/data/core/units/dwarves/Scout.cfg#L21 20180511 22:56:00< mattsc> It’s because the Dwarvish Scout counts as a mixed fighter 20180511 22:57:27< sevu> Of cause. Thanks 20180511 23:01:09-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180511 23:02:50< irker328> wesnoth/wesnoth:master Severin Glöckner 1f75c5b14d NR S2: remove second endlevel event for AppVeyor: vs2017/Debug Failed 20180511 23:02:51< irker328> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-2979 20180511 23:21:22-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 23:21:28-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 23:22:45-!- gallaecio [~quassel@213.99.45.54] has quit [Remote host closed the connection] 20180511 23:26:13-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180511 23:31:14-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 23:31:15-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has quit [Ping timeout: 256 seconds] 20180511 23:31:20-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180511 23:32:35-!- gfgtdf [~chatzilla@x4e32b1f9.dyn.telefonica.de] has joined #wesnoth-dev 20180511 23:33:10-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180511 23:54:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180511 23:54:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev --- Log closed Sat May 12 00:00:43 2018