--- Log opened Mon Nov 07 00:00:01 2016 --- Day changed Mon Nov 07 2016 20161107 00:00:00< celticminstrel> vultraz, zookeeper: ^ 20161107 00:00:07< vultraz> yes 20161107 00:01:08-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind] 20161107 00:02:29-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds] 20161107 00:10:08-!- stikonas_ is now known as stikonas 20161107 00:19:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20161107 00:19:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161107 00:26:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20161107 00:26:53-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161107 00:31:57< irker528> wesnoth: Charles Dang wesnoth:master 1167bc3c3c36 / src/ (attack_prediction.cpp controller_base.cpp): Convert uses of fabs to std::fabs https://github.com/wesnoth/wesnoth/commit/1167bc3c3c36adda78f9d5358f032dd69e561886 20161107 00:32:00< irker528> wesnoth: Charles Dang wesnoth:master 1fa6a2d4b231 / src/ (22 files in 13 dirs): Convert uses of abs to std::abs https://github.com/wesnoth/wesnoth/commit/1fa6a2d4b23103c48ee9bb380a5535fcaa657edd 20161107 00:45:10-!- louis94 [~~louis94@91.178.241.163] has quit [Ping timeout: 250 seconds] 20161107 00:48:12-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 260 seconds] 20161107 00:52:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161107 00:52:22-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20161107 00:54:47-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev 20161107 01:21:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161107 01:36:02-!- travis-ci [~travis-ci@ec2-54-162-239-60.compute-1.amazonaws.com] has joined #wesnoth-dev 20161107 01:36:03< travis-ci> wesnoth/wesnoth#11902 (master - 1fa6a2d : Charles Dang): The build was broken. 20161107 01:36:03< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173775124 20161107 01:36:03-!- travis-ci [~travis-ci@ec2-54-162-239-60.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161107 01:40:49< irker528> wesnoth: Charles Dang wesnoth:master 39d6a5a7f157 / src/tests/test_formula_function.cpp: Revert 1fa6a2d4b231 change to tests https://github.com/wesnoth/wesnoth/commit/39d6a5a7f157bd8b9ea6378b401aa7e8fd381b8a 20161107 02:05:29< irker528> wesnoth: Charles Dang wesnoth:master dc477afb7a61 / / (14 files in 6 dirs): Removed empty sdl/image.*pp files https://github.com/wesnoth/wesnoth/commit/dc477afb7a617b55018aa7e135b3cb0c90349cd3 20161107 02:06:05< celticminstrel> :| 20161107 02:06:12< celticminstrel> I did that earlier. 20161107 02:06:19< celticminstrel> I even mentioned it. 20161107 02:06:28 * celticminstrel sigh. 20161107 02:06:42< celticminstrel> Well, I guess it won't cause conflicts, at least. I just need to update the commit message. 20161107 02:08:20-!- gfgtdf_ [~chatzilla@x4e36a8b5.dyn.telefonica.de] has joined #wesnoth-dev 20161107 02:08:39< celticminstrel> Maybe. I can't remember. 20161107 02:10:26-!- gfgtdf [~chatzilla@x4e369b2b.dyn.telefonica.de] has quit [Ping timeout: 252 seconds] 20161107 02:10:29-!- gfgtdf_ is now known as gfgtdf 20161107 02:15:12< vultraz> oh? 20161107 02:15:15< vultraz> sorry :( 20161107 02:20:37-!- travis-ci [~travis-ci@ec2-54-162-239-60.compute-1.amazonaws.com] has joined #wesnoth-dev 20161107 02:20:38< travis-ci> wesnoth/wesnoth#11903 (master - 39d6a5a : Charles Dang): The build was fixed. 20161107 02:20:38< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173781834 20161107 02:20:38-!- travis-ci [~travis-ci@ec2-54-162-239-60.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161107 02:25:53< tad_carlucci> vultraz, check src/sdl/shader.*pp for possible deletion as well 20161107 02:26:19-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer] 20161107 02:26:42-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev 20161107 02:26:42-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host] 20161107 02:26:42-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev 20161107 02:26:55< irker528> wesnoth: Charles Dang wesnoth:master d53c87c7ee1c / src/ (image.cpp preferences.cpp): Made use of util::clamp https://github.com/wesnoth/wesnoth/commit/d53c87c7ee1c51db007c1bb4f3d9fa0886ab8abc 20161107 02:26:55< celticminstrel> What was the class defined there? tshader? 20161107 02:27:10 * celticminstrel didn't delete that file, so feel free to if you think it should be. 20161107 02:28:05< vultraz> what? 20161107 02:28:16< vultraz> oh 20161107 02:28:31< vultraz> shader_program 20161107 02:30:34< irker528> wesnoth: Charles Dang wesnoth:master dbb21314eaf7 / src/ (CMakeLists.txt sdl/shader.cpp sdl/shader.hpp): Removed empty sdl/shader.*pp files https://github.com/wesnoth/wesnoth/commit/dbb21314eaf7baf1e7393fc9a2532edb696304e0 20161107 02:37:58-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009] 20161107 02:38:11-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20161107 02:41:49< tad_carlucci> vultraz, And while your in a deleting mood: rm -fR src/tools/sdl2 and commit ??? 20161107 02:42:24< vultraz> loonycyborg: where do i find the sha256 hash for the windows installer again? 20161107 02:42:44< vultraz> tad_carlucci: i thought you were going to do that 20161107 02:42:50< vultraz> tad_carlucci: but if you want i can do it 20161107 02:43:36< tad_carlucci> vultraz, Go ahead. I'm still working through my list of cruft. 20161107 02:45:53< irker528> wesnoth: Charles Dang wesnoth:master 2cf200f51a13 / src/ (5 files in 2 dirs): Removed SDL 2 test tools https://github.com/wesnoth/wesnoth/commit/2cf200f51a13574898b3445f04c7066a0e4dec40 20161107 02:46:33< vultraz> tad_carlucci: ^ 20161107 02:49:30< shadowm> vultraz: https://files.wesnoth.org/releases/ 20161107 02:49:55< tad_carlucci> vultraz, Admin CMD console: C:\Windows\system32\CertUtil.exe -hashfile SHA1 if you need to check/generate it 20161107 02:50:19< celticminstrel> Four days since I sent the message about dropping libintl. 20161107 02:50:22< celticminstrel> No responses. 20161107 02:50:29< celticminstrel> Should we go ahead and do it? 20161107 02:50:43< vultraz> yes. 20161107 02:50:45< tad_carlucci> yes 20161107 02:51:01< celticminstrel> So delete src/gettext.cpp, right? 20161107 02:51:08< celticminstrel> And remove references from the scons and cmake. 20161107 02:51:30< tad_carlucci> A bit more. Need to take out the feature tests, too, I'd think. 20161107 02:52:12< celticminstrel> There might be more. 20161107 02:52:17< celticminstrel> I have no idea. 20161107 02:53:33< tad_carlucci> There will be options, feature tests, library references and defines. As well as the source files. 20161107 02:54:09< celticminstrel> BTW, does 'git grep shader_program' turn up anything now? 20161107 02:54:20< vultraz> git grep? 20161107 02:54:24< celticminstrel> And 'git grep sdl::timage', other than in floating_text? 20161107 02:54:25< celticminstrel> Yes. 20161107 02:54:47< vultraz> what is git grep 20161107 02:54:51< celticminstrel> git grep is automatically recursive and restricted to tracked files, and offers git-specific options. 20161107 02:55:24< vultraz> i just use n++'s find in files function 20161107 02:55:27< vultraz> anyway, first, no 20161107 02:55:34 * celticminstrel removed references to sdl::timage in floating_text.cpp, was just wondering if there are others. 20161107 02:55:35< vultraz> second, only in floating_label.*pp 20161107 02:55:44< celticminstrel> Oh sorry, floating_label. 20161107 02:55:45< celticminstrel> Whatever. 20161107 02:55:50< celticminstrel> Okay, so I removed those. 20161107 02:56:45< celticminstrel> I wish less had an option to show how much is left in the file. 20161107 02:56:56< celticminstrel> Well, admittedly, this is a pipe, not a file, but... 20161107 02:59:27< celticminstrel> (Another git gripe - "git commit -a" is not equivalent to "git add -a; git commit". Instead it's equivalent to "git add -u; git commit". Why can't it use -a for both cases?) 20161107 02:59:53< celticminstrel> (git add doesn't even have an -a flag either.) 20161107 03:01:29< gfgtdf> celticminstrel: when remcong gettext.cpp you coudl mabe cleanup language.cpp aswell, my hopy is that we can remove the language_win32.ii file then 20161107 03:01:52< celticminstrel> Why the heck is there a preprocessed file? 20161107 03:02:30< gfgtdf> there is also a filesystem_win32.ii file mentioned in multiple projectfiles, but i couldnt find teh actual file so maybe teh projectfiles are just outdated here 20161107 03:03:00< shadowm> Yes. 20161107 03:03:39< gfgtdf> wedge009: ^ iirc you currently maintain those files ? 20161107 03:03:41< shadowm> git log -- src/filesystem_win32.ii will reveal exactly what happened to it. 20161107 03:05:07< tad_carlucci> celticminstrel, vultraz, gfgtdf On a sorta related subject: The comments in src/font/sdl_tff.cpp about HAVE_FRIBIDI ... are we at a point where the (buggy) legacy library can be eliminated? 20161107 03:05:32< vultraz> I don't know 20161107 03:05:33< celticminstrel> SDL_TTF could probably be eliminated with a little work. 20161107 03:05:43< gfgtdf> maybe shadowm knows 20161107 03:05:48< vultraz> SDL_TTF is on its way out, at least 20161107 03:05:54< vultraz> but not yet 20161107 03:06:04< shadowm> The SDL_ttf API wants FriBiDi. 20161107 03:06:07< celticminstrel> Font surface caching might be something to transfer to the other text rendering implementation. 20161107 03:06:22< shadowm> But our usage of FriBiDi is rumored to be broken anyway. 20161107 03:06:27< tad_carlucci> It says "// Oron -- Conditional, until all draw_text_line calls have fixed area parameter" 20161107 03:06:36< shadowm> I don't know. Don't hold me responsible for anything that comes out of this. 20161107 03:07:34< shadowm> It should be obvious to everyone at this point that the SDL_ttf API is still needed until GUI1 is fully purged unless someone takes the time to make GUI1 use ttext instead. 20161107 03:07:54< tad_carlucci> fribidi is broken if you have multiline text to lay out. If it's always only one line, and never wraps, it's supposedly 'good enough' but that's just my impression from reading up on the issue a few weeks ago. 20161107 03:08:49< vultraz> indeed, we can drop sdlttf if we make gui2 use ttext 20161107 03:08:58< shadowm> GUI1 vultraz, GUI1. 20161107 03:09:04< vultraz> er 20161107 03:09:06< vultraz> yes 20161107 03:09:09< vultraz> typo 20161107 03:09:23< shadowm> It's going to be non-trivial work, I can tell you that for sure. 20161107 03:09:48< shadowm> Otherwise I'd have fixed that bug we don't talk about ages ago. 20161107 03:09:49< vultraz> yes 20161107 03:10:07< vultraz> which is why it might just be better to wait until gui1 goes away 20161107 03:10:18< vultraz> it's slowly doing so 20161107 03:10:37< celticminstrel> The only big things left are ThemeUI and helpd dialog, right? 20161107 03:10:45< celticminstrel> ^help dialog 20161107 03:10:47< shadowm> At least GUI1 is barely used for multi-line text anymore. 20161107 03:10:58< celticminstrel> You have a point there. 20161107 03:11:17< shadowm> The only remaining multi-line user is probably the help browser, since tooltips are rendered using ttext and the theme UI seems to exclusively use single-line layouts. 20161107 03:11:41< celticminstrel> What about ThemeUI tooltips? 20161107 03:11:47< shadowm> ttext. 20161107 03:11:53< celticminstrel> Really? Okay then. 20161107 03:12:02< celticminstrel> But they're not GUI2 tooltips, right? 20161107 03:12:05< vultraz> no. 20161107 03:12:10< vultraz> they could be made so 20161107 03:12:15< vultraz> maube 20161107 03:12:15< celticminstrel> No, they could not. 20161107 03:12:17< vultraz> maybe 20161107 03:12:19< shadowm> They weren't in 1.12 despite using ttext, that's all I know. 20161107 03:12:28< celticminstrel> For the same reasons that I abandoned the GUI2 floating textbox. 20161107 03:12:34< vultraz> uh... 20161107 03:12:42< vultraz> no, tooltips are windows, remember :| 20161107 03:12:43< shadowm> (Just like in 1.12 the storyscreen uses ttext in combination with GUI1 widgets and nothing from GUI2 at all.) 20161107 03:12:57< vultraz> you were trying to make a widget display sans window 20161107 03:13:12< celticminstrel> vultraz: No, I tried that, but then I switched to making it a window. 20161107 03:13:29< vultraz> I see... 20161107 03:13:49< celticminstrel> The current version is a dialog extending tpopup. It actually worked better than the bare widget, but that's not saying much. 20161107 03:14:16< celticminstrel> It's somethng about the fact that GUI2 uses a separate event handling system. 20161107 03:14:18< celticminstrel> ^something 20161107 03:14:36< celticminstrel> So GUI2 tooltips are unlikely to work any better than the floating textbox did. 20161107 03:15:08< vultraz> shrug shrug 20161107 03:15:23< vultraz> anyway, I might tackle the help browser this release 20161107 03:15:36< celticminstrel> Really? I was considering looking at that too. 20161107 03:15:57< vultraz> you can do the addons manager :P 20161107 03:16:17< celticminstrel> Eh... 20161107 03:16:25 * celticminstrel actually forgot that wasn't finished. 20161107 03:16:49< vultraz> i suppose i should work on that myself but it's going to be a massive effort :( 20161107 03:17:13< vultraz> and a massive paradigm shift >_> 20161107 03:17:33< vultraz> since I want to make it so multiple addons can be downloaded at once without waiting for each one to finish 20161107 03:18:04< celticminstrel> What's with the const pointer typedefs all using different positions. 20161107 03:18:19< celticminstrel> "const_xxx_ptr" or "xxx_const_ptr" or maybe even "xxx_ptr_const". 20161107 03:18:29< vultraz> no idea 20161107 03:19:07< vultraz> i wonder if it'd be possible to make addons download even when exiting the manager 20161107 03:19:43< vultraz> probably not 20161107 03:19:55< tad_carlucci> vultraz, Sure, if you want to make a background thread. You can even detach it so it finished if you "close" the program. 20161107 03:20:07< vultraz> ;_; 20161107 03:20:14 * vultraz doesn't want to have to learn threading 20161107 03:21:04< vultraz> especially not networking + threading 20161107 03:21:44< vultraz> and *especially* not threading + networking + ui 20161107 03:22:25< Aginor> ui+threading should go hand in hand 20161107 03:22:58< Aginor> threading+networking too, depending on your networking model 20161107 03:23:59< tad_carlucci> The only issue I can see with background loading an addon, especially a number of them, is if you DON'T wait and DON'T close the program, and try to do something they'll effect you might get some strange behaviors. 20161107 03:24:45< vultraz> it could all be done, but it's just... so above my level :| 20161107 03:25:51< tad_carlucci> Actually, then, it's a good place to learn. Do the downloads to a temp location. Think "separate program" but no "main()" and "when I'm done I lock the world and install them" 20161107 03:26:50< celticminstrel> BTW, downloading an addon is a place where the progress bar widget should be used. 20161107 03:26:53< tad_carlucci> That last part may be "if there's a game running I leave them in the temp are and install them next time the engine starts" 20161107 03:26:59< celticminstrel> (Though I seem to recall it being deleted for no reason?) 20161107 03:27:02< vultraz> celticminstrel: obviously.. 20161107 03:27:09< celticminstrel> (Maybe that was something else?) 20161107 03:27:20< vultraz> celticminstrel: gui1 one 20161107 03:27:30< celticminstrel> Ah. 20161107 03:27:42< tad_carlucci> Some people punt and do the install-on-startup and simply say, "To use the addon, restart the engine." 20161107 03:28:02< vultraz> well, the only thing really needed to "install" an addon is a config refresh 20161107 03:28:45< tad_carlucci> vultraz, Consider what that means to a running scenario or campaign. If it's not a problem to refresh the config, then fine. 20161107 03:28:52< celticminstrel> That's not quite true. 20161107 03:28:59< vultraz> i suppose the first thing i should do is make the dialog work 20161107 03:29:07< vultraz> downloads/installs/whatever 20161107 03:29:09< celticminstrel> You need to copy it into the addons directory too. That's part of installing. 20161107 03:29:13< vultraz> and terminate any when the dialog closes. 20161107 03:29:21< celticminstrel> Why terminate? 20161107 03:29:32< vultraz> I said *first* thing 20161107 03:29:35< celticminstrel> You're not using the network transmission dialog? 20161107 03:29:40< vultraz> get the networking working 20161107 03:29:42< vultraz> and no, I am not 20161107 03:29:48< vultraz> it will be an in-dialog progress bar 20161107 03:29:51< celticminstrel> Ah okay. 20161107 03:30:06< celticminstrel> Then if you try to leave while a download is in progress, it should ask if you want to cancel it. 20161107 03:30:07< vultraz> so, get the networking working 20161107 03:30:10< vultraz> then figure threading 20161107 03:30:16< vultraz> obviously... 20161107 03:30:20< vultraz> do you think I'm stupid :| 20161107 03:30:28< celticminstrel> (And possibly auto-close if the transfer completes before you choose...) 20161107 03:30:50< vultraz> that might be more complicated 20161107 03:30:52< celticminstrel> I have no idea what you consider obvious. 20161107 03:31:11< celticminstrel> It doesn't hurt to say obvious things, anyway. 20161107 03:31:20< celticminstrel> So I might as well say them in case they're not obvious to someone else. 20161107 03:31:30< vultraz> true 20161107 03:31:33< tad_carlucci> Just remember, if you want to thread it into the background at some point everything it does needs to be isolated. Don't just update the dialog or whatever .. make a function .. because when it's in another thread you'll have to "send a message" across the boundary to avoid nastiness. 20161107 03:31:39< vultraz> and I have been known to ask stupid questions 20161107 03:32:13< celticminstrel> You probably want a condition variable. 20161107 03:32:41< celticminstrel> If this were Java, the function that sets the progress bar would be declared "synchronized". 20161107 03:32:44< tad_carlucci> yes. and isolated into a function because you're going to want to wrap it in a mutex eventually. 20161107 03:32:46< vultraz> essentially i wanted to implement a download queue system 20161107 03:32:53< celticminstrel> So basically, emulate that with a condition variable. 20161107 03:33:04< vultraz> instead of right now, where the dialog immediately closes and the download starts 20161107 03:33:08< celticminstrel> IIRC every object is a condition variable in Java. 20161107 03:33:17< celticminstrel> Please correct me if I'm using the wrong terms. 20161107 03:33:21< vultraz> though actually I think there might be something similar.. 20161107 03:33:30< vultraz> since on can update a bunch of addons at once 20161107 03:33:54< vultraz> right now i was just thinking... have a dialog timer\ 20161107 03:34:02< celticminstrel> Download queue shouldn't be too hard to implement. Why a timer? 20161107 03:34:08< vultraz> that constantly checks for something in the queue 20161107 03:34:13< celticminstrel> Shove pending downloads into the queue. 20161107 03:34:14< vultraz> then if there's something 20161107 03:34:17< tad_carlucci> Gak 20161107 03:34:19< vultraz> start download 20161107 03:34:20< celticminstrel> When one finishes, check if there's another one. 20161107 03:34:21< vultraz> and poll the network 20161107 03:34:25< vultraz> and update the widgets.. 20161107 03:34:41< celticminstrel> If there isn't, just stop. There won't be another until someone clicks a download button anyway. 20161107 03:34:52< celticminstrel> No need for timers. 20161107 03:35:09< celticminstrel> Except maybe for the network polling, though we've already discussed that that's not a great way to do network polling. 20161107 03:35:19< vultraz> i need to constantly poll the network for progress 20161107 03:35:20< vultraz> remember 20161107 03:35:29< vultraz> :| 20161107 03:35:45< celticminstrel> But it would be better to process data from the network as soon as it arrives, right? 20161107 03:36:22< vultraz> yes, but *how* 20161107 03:36:32< vultraz> it hasn't been implemented yet! 20161107 03:36:35< celticminstrel> I don't know how ASIO works. 20161107 03:36:44< celticminstrel> But something in its API probably allows you to do that. 20161107 03:36:48< vultraz> (it = custom callbacks in our network code) 20161107 03:38:18< vultraz> maybe the wesnothdconnection dialog has something 20161107 03:38:20< vultraz> idk 20161107 03:38:21< gfgtdf> vultraz: you'd need add a thread that calls .run on th asio::io_service and then use SDL_PushEvent in the io_service ahdnerls to send those updates to the main thread. 20161107 03:38:25< vultraz> this is all so complicated 20161107 03:38:38< vultraz> gfgtdf: i have no idea what any of that means! 20161107 03:38:40< vultraz> :( 20161107 03:38:44< gfgtdf> vultraz: wesnothdconnection is designed to communicate with the wesnothd server 20161107 03:39:11< vultraz> oh right 20161107 03:39:16< vultraz> network connect dialog 20161107 03:39:23< vultraz> what it uses right now for downloading addons.. 20161107 03:39:26< gfgtdf> vultraz: network_asio.cpp contins the code for the campaignd socket, its similar to the wesnothdconnection calss but not the same 20161107 03:40:06< gfgtdf> class* 20161107 03:40:57< vultraz> anyway, im not going to work on this now 20161107 03:41:18< vultraz> if uh... 20161107 03:41:25< vultraz> i have time ill see what i can do 20161107 03:48:45< vultraz> celticminstrel: for 1.13.7 I'm gonna need you to (if possible) deal with (either finish or discard) team index refactor, menu item cleanup, and spiritpo. 20161107 03:48:56< vultraz> shadowm: your job is to find a way to bring that blinking textbox cursor back 20161107 03:49:15< celticminstrel> Right, spirit_po. 20161107 03:49:16< vultraz> jyrki: i need you to finish your grid stuff and continue working on your ui improvements/todo list 20161107 03:49:37< vultraz> tad_carlucci: im not sure what you're working on, but keep working on it, and see if you can do any campaign work 20161107 03:50:27< celticminstrel> I was thinking maybe I should make Wesnoth try Boost.Locale first for messages, and if that fails, look for a loadable po-file and use spirit_po. 20161107 03:50:54< vultraz> Aginor: i need you to focus on finishing your canvas refactor 20161107 03:50:58< vultraz> uhh who else.. 20161107 03:51:39< vultraz> gfgtdf: you're on bugfix duty 20161107 03:51:48< vultraz> and I'm going to focus on more UI stuff 20161107 03:52:06< Aginor> vultraz: ? 20161107 03:52:45< vultraz> Aginor: im assigning general jobs for 1.13.7. yours is just to finish what you're already working on. 20161107 03:54:10-!- vultraz changed the topic of #wesnoth-dev to: 1.13.6 tagged, announcing "soon", 1.13.7 tentatively scheduled for December 18th (00:00 UTC) | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org 20161107 03:54:29< vultraz> if we don't hit that, next target is early January 20161107 03:55:05< vultraz> I don't expect anyone to work over Christmas, so let's try to wrap up as much stuff before then. 20161107 03:55:41< vultraz> We need to get 1.14 RC1 out sometime in February or at *latest* early March. 20161107 03:55:52< vultraz> but preferably February. 20161107 03:56:13< vultraz> sometime around Valentine's Day. 20161107 03:57:04< vultraz> zookeeper's job is utbs 20161107 03:57:23< celticminstrel> That wasn't finished? 20161107 03:57:52< vultraz> well, since it still exists side-by-side with the original I'd say not 20161107 03:59:26< vultraz> anyway, I'm hoping we can get 1.13.7 out on December 18th 20161107 03:59:32< vultraz> 1.13.8 out by the end of January 20161107 03:59:48< vultraz> and 1.13.9 aka 1.14 RC1 out by mid-February 20161107 04:00:10< shadowm> vultraz: You can't really order me around, you know. 20161107 04:01:21< vultraz> I'm assigning you a task. Whether you do it or not is up to you. 20161107 04:01:31< shadowm> The only GUI thing that was officially my responsibility already was the file dialog. The blinking text cursor is just a bonus project I came up with on a whim. 20161107 04:01:48< shadowm> I may or may not finish it and it's wholly inconsequential to everything. 20161107 04:02:25< shadowm> People won't die if they still don't have blinking cursors 14 years after Wesnoth was founded. 20161107 04:03:52< shadowm> Also, it's much harder to remember these directions from an IRC conversation than from a wiki page or email message. 20161107 04:04:17< shadowm> People won't dig up this log 30 days later to recheck who is doing what. 20161107 04:04:22< vultraz> As I said, whether you choose to complete it or not is up to you. 20161107 04:04:44< vultraz> You have other stuff to work on too. 20161107 04:04:48< celticminstrel> I'm not sure I'll revisit the menu refactor though. 20161107 04:04:53< vultraz> Which renders the cursor rather minor. 20161107 04:05:00< celticminstrel> Spirit Po and team index, I can probably get to. 20161107 04:05:02< shadowm> (In other words, what ever happened to that plan to complete an actual schedule page on the wiki...) 20161107 04:06:33< celticminstrel> (I did rebase spirit_po recently, I think. Definitely tried to, at least.) 20161107 04:06:51< vultraz> celticminstrel: if you're not going to continue it, discard it. 20161107 04:06:56< celticminstrel> I'm actually more interested in the wml_tag_porting branch, though. 20161107 04:07:09< vultraz> oh yeah 20161107 04:07:11< vultraz> that too 20161107 04:07:32< celticminstrel> Also want to do the WFL functions defined in Lua thing, but not sure I'll get to it. 20161107 04:07:47< celticminstrel> BTW, a few hours ago I was wondering whether I should add bitwise operators to WFL? 20161107 04:08:09< DeFender1031> vultraz, is the idea to have 1.14 ready for the steam release? 20161107 04:08:20< vultraz> yes 20161107 04:08:20< celticminstrel> Not really any particular reason for it, just occurred for me. 20161107 04:08:25< vultraz> oh, I almost forgot you 20161107 04:08:31< celticminstrel> It would be fairly easy to do. 20161107 04:08:35< vultraz> DeFender1031: you need to do your string cleanuo 20161107 04:08:37< vultraz> p 20161107 04:08:58< DeFender1031> vultraz, obviously. 20161107 04:10:52< tad_carlucci> Something is bolixed in the Lua console. Very slow .. like multiple seconds for a keypress. Is this known or new? 20161107 04:11:24< celticminstrel> DeFender1031: Your markup is broken in one of your posts. 20161107 04:11:35< celticminstrel> tad_carlucci: I've experienced that sometimes. 20161107 04:11:46< celticminstrel> In Lua console, in formula debugger, and in login dialog when connecting to the server. 20161107 04:12:29< celticminstrel> At least, it looks broken to me. 20161107 04:12:44< tad_carlucci> Let me kill it and try something. 20161107 04:12:46< DeFender1031> celticminstrel, it is? 20161107 04:12:50< Aginor> vultraz: I agree with shadowm, and the things you doled out are not the more important things 20161107 04:12:58< celticminstrel> DeFender1031: "wesnoth.scenario.[\c]...something? Though I suppose [c].current" 20161107 04:13:08< Aginor> whether I do anything or not to the canvas is inconsequential to 1.14 20161107 04:13:25< Aginor> whether I go and fix the remaining flickering when looking at a [message] is less so 20161107 04:13:35< DeFender1031> celticminstrel, ah, yes, that should not be a backslash 20161107 04:14:12 * vultraz groans 20161107 04:14:58< DeFender1031> celticminstrel, fixed 20161107 04:15:19< Aginor> vultraz: and making the release plan public on the wiki is far more helpful than an IRC conversation that nobody will remember or easily find in a couple of days 20161107 04:15:47< vultraz> yes I will concoct a list :| 20161107 04:15:59-!- gfgtdf [~chatzilla@x4e36a8b5.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]] 20161107 04:16:05< vultraz> I'm just giving people a few tasks. 20161107 04:16:17< vultraz> I'll make a nice list later 20161107 04:16:24< tad_carlucci> And it needs to be classified. "Must have" "Should have" "Might have" and the not's 20161107 04:17:31< vultraz> yes, yes, yes 20161107 04:19:28< tad_carlucci> celticminstrel, I thought maybe it was something to do with HAVE_HISTORY but I have a build without history and the Lua console is still slow. 20161107 04:19:58< celticminstrel> I think it's something to do with draw events flooding the queue. 20161107 04:20:09< celticminstrel> Something which vultraz probably made worse recently. 20161107 04:20:25< celticminstrel> By reducing the interval at which they fire. 20161107 04:21:01< Aginor> oh, is that not fixed yet 20161107 04:21:08< celticminstrel> (Why do they even fire on an interval anyway?) 20161107 04:21:20< Aginor> celticminstrel: so it renders at 50fps 20161107 04:21:31< Aginor> and no faster 20161107 04:21:40< celticminstrel> Is that really the way to do that? 20161107 04:21:51< vultraz> *why* 50... and not 60.. 20161107 04:21:59< Aginor> I'd say "no" LD 20161107 04:27:27< tad_carlucci> Why re-render frames at 50fps when it doesn't change unless I press a key or something ran and produced output? 20161107 04:36:30-!- prkc_ [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Read error: Connection reset by peer] 20161107 04:36:35< celticminstrel> BTW vultraz, I'm renaming the matrix placement policy to "table" if you have no complaints. 20161107 04:36:48< vultraz> sure 20161107 04:36:49< celticminstrel> That should make it easier to speak of it separately from the matrix widget. 20161107 04:37:41< celticminstrel> I wonder if I should make separate "table" and "flow" policies... with "flow" being based on current and "table" ensuring the cells line up... 20161107 04:39:46< vultraz> nah 20161107 04:40:41< vultraz> we only need table 20161107 04:42:35< celticminstrel> I think this commit might be getting a bit big... 20161107 04:43:45< celticminstrel> Definitely not more than 300 files... 20161107 04:43:58< celticminstrel> Probably not more than 1500 lines per file... 20161107 04:46:45< tad_carlucci> celticminstrel, Why is the apple source file src/desktop/apple_notification.mm and mm file? More importantly, is there an issue with changing the #include for its header to add "desktop/" in keeping with the same changes I made elsewhere? 20161107 04:47:06< celticminstrel> tad_carlucci: .mm indicates Objective-C++ code. 20161107 04:47:20< celticminstrel> There should be no problem with changing its #include. 20161107 04:47:44< tad_carlucci> OK. I can't test it but I'm adding that to my PR. 20161107 04:48:24< celticminstrel> I probably can't test that myself since it uses APIs that don't exist on my machine. 20161107 04:48:36 * tad_carlucci rolls his eyes. 20161107 04:48:37< tad_carlucci> OK 20161107 04:48:39< celticminstrel> At least, I'm pretty sure they don't. I think desktop notifications were added in 10.9. 20161107 04:48:48< celticminstrel> I only have the 10.8 SDK. 20161107 04:48:58< celticminstrel> (Even though I'm on 10.7. Apparently XCode 4 just comes with it.) 20161107 04:50:01< tad_carlucci> 10.8 -> NS notifications // also "growl" with no version check 20161107 04:50:32< celticminstrel> Ah, so maybe I can test it after all if I tell it to try a release build. 20161107 04:50:36< celticminstrel> Not sure I'll get to it though. 20161107 04:50:50< celticminstrel> (Release build uses 10.8 SDK. Debug build uses current SDK, ie 10.7.) 20161107 04:50:59< tad_carlucci> Ah 20161107 04:51:18< celticminstrel> (Actually, technically release uses "latest available SDK", I think.) 20161107 04:51:21< tad_carlucci> Well, so long as the #include change doesn't break things for Objective C 20161107 04:51:24< celticminstrel> (But it's 10.8 for me.) 20161107 04:51:33< celticminstrel> Shouldn't break anything. 20161107 04:55:58< tad_carlucci> Well, my custom Makefile for this out-of-tree build says (--version) it's matching SCons and CMake. I need to re-run my check for unused files and see what I missed. 20161107 04:59:57-!- JyrkiVesterinen [~jyrki@87-100-148-95.bb.dnainternet.fi] has joined #wesnoth-dev 20161107 05:03:44-!- astrelyon [~astrelyon@78.134.230.190] has quit [Quit: WeeChat 1.4] 20161107 05:55:53-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Read error: Connection reset by peer] 20161107 06:02:15-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.] 20161107 06:16:54< celticminstrel> vultraz: What should I do with tselectable_ and the like? 20161107 06:17:02< vultraz> _base 20161107 06:17:06< vultraz> ? 20161107 06:17:25< celticminstrel> They basically represent an interface that widgets can implement. 20161107 06:17:45< celticminstrel> tselectable_ is not itself a widget; it's just a small behaviour class. 20161107 06:17:49-!- irker528 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161107 06:18:04< celticminstrel> Otherwise unrelated widgets can inherit from it to support similar behaviour. 20161107 06:18:17< celticminstrel> I thought "intf_selectable" but that's a bit ugly. 20161107 06:18:42< celticminstrel> (And is already used in the Lua bindings.) 20161107 06:18:47< celticminstrel> (For functions rather than classes.) 20161107 06:19:29 * celticminstrel also counts tinteger_selector in this category, but not eg ttext_ or tscrollbar_ 20161107 06:19:52< vultraz> selectable_helper? 20161107 06:20:13< celticminstrel> I suppose I could do that. I don't feel that it represents the meaning well, but it does sorta work. 20161107 06:22:27< celticminstrel> vultraz: So should I go with that, then? 20161107 06:23:03< vultraz> i can't think of anything else besides selectable_base 20161107 06:23:34< celticminstrel> Maybe selectable_interface? Or selectable_item? I dunno. 20161107 06:25:31< vultraz> item could work 20161107 06:25:33< vultraz> not interface 20161107 06:25:46< celticminstrel> What about tinteger_selector then? 20161107 06:26:04< celticminstrel> I suppose I could just leave that as integer_selector... 20161107 06:26:26 * celticminstrel also thinks that menu_button shouldn't extend tselectable_ 20161107 06:26:52 * celticminstrel naybe 20161107 06:26:56< celticminstrel> ^maybe 20161107 06:29:27< vultraz> that could also have _helper appended 20161107 06:29:32< vultraz> though it seems alright as-is 20161107 06:30:13< celticminstrel> Can I rename tlist -> list_view? 20161107 06:30:35< vultraz> yes 20161107 07:14:03-!- JyrkiVesterinen [~jyrki@87-100-148-95.bb.dnainternet.fi] has quit [Quit: .] 20161107 07:20:21-!- celticminstrel is now known as celmin|sleep 20161107 07:34:32-!- celmin|sleep [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20161107 07:35:40-!- irker539 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161107 07:35:40< irker539> wesnoth: Charles Dang wesnoth:master aa96353dfaaf / src/sdl/rect.cpp: Mark empty_rect as constexpr https://github.com/wesnoth/wesnoth/commit/aa96353dfaafeb4dea244c5f867cec19d1b073e7 20161107 08:04:51< vultraz> 86 bugs to close this release :D 20161107 08:08:08-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has joined #wesnoth-dev 20161107 08:08:34-!- travis-ci [~travis-ci@ec2-54-158-207-63.compute-1.amazonaws.com] has joined #wesnoth-dev 20161107 08:08:35< travis-ci> wesnoth/wesnoth#11910 (master - aa96353 : Charles Dang): The build was broken. 20161107 08:08:35< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173820285 20161107 08:08:35-!- travis-ci [~travis-ci@ec2-54-158-207-63.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161107 08:15:09-!- boucman_work [~boucman@fw-alt.idf.smile.fr] has joined #wesnoth-dev 20161107 08:20:26 * vultraz 's hand hurts after closing all 86 bugs 20161107 08:21:01< vultraz> we now have 666 open bugs :D 20161107 08:22:58-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161107 08:26:57< vultraz> JyrkiVesterinen: will your grid PR fix widgets' default_width/default_height keys not working, and min_width/min_width acting oddly in some cases? 20161107 08:27:27< vultraz> for example, if I assign default_height = 800 to the unit preview pane, the size isn't respected... 20161107 08:27:34< JyrkiVesterinen> I haven't even heard of such keys before. 20161107 08:27:48< vultraz> if do min_height = 800, it seems to *add* 800 to the height.. 20161107 08:27:58< JyrkiVesterinen> They aren't mentioned in the layout documentation wiki page, and I haven't seen references to them in code either. 20161107 08:28:34< vultraz> JyrkiVesterinen: https://github.com/wesnoth/wesnoth/blob/master/src/gui/core/widget_definition.cpp#L95-L100 20161107 08:29:11-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20161107 08:29:32< vultraz> they seem to be used in tcontrol 20161107 08:29:37< vultraz> get_config_minimum_size 20161107 08:29:42< vultraz> get_config_default_size 20161107 08:29:45< vultraz> get_config_maximum_size 20161107 08:30:46< vultraz> and then used in tcontrol::calculate_best_size().. 20161107 08:31:12< vultraz> but for some reason get_config_default_size is treated as a minimum.. 20161107 08:31:29< vultraz> JyrkiVesterinen: i can't really make sense of this :/ 20161107 08:31:59< vultraz> it really seems like something that shouldn't be exclusive to tcontrol 20161107 08:32:05< vultraz> (timage uses it too, though) 20161107 08:32:19< vultraz> but should be handled in twidget or tgrid 20161107 08:34:36< vultraz> JyrkiVesterinen: one would think these keys would make the layout functions try default size, then min size, but also respect max size when they grow :/ 20161107 08:34:51< JyrkiVesterinen> Hmm, I hadn't seen the tcontrol code before. Indeed, based on some code reading a widget author can set the minimum, maximum and default sizes for a widget, and they seem to be respected for the size calculation of widgets. 20161107 08:35:29< JyrkiVesterinen> vultraz: Maximum sizes at least are completely ignored. Tgrid::place() doesn't try to take them into account at all. 20161107 08:37:39< vultraz> right. but default doesn't seem to do anything, and in the case of the unit preview pane, min makes this happens: https://drive.google.com/file/d/0B-mR9s8FduLLX0lDdGg0LWlSVFE/view?usp=sharing 20161107 08:37:45< vultraz> (using min_height = 800) 20161107 08:38:14< vultraz> it's all very weird :/ 20161107 08:38:23< JyrkiVesterinen> Looking closer, tcontrol::calculate_best_size() and tcontrol::request_reduce_width() return early if label_ is empty and ignore the default/minimum/maximum sizes. 20161107 08:38:38< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/master/src/gui/widgets/control.cpp#L230-L233 20161107 08:38:49< JyrkiVesterinen> I suspect that's the case for nearly all controls... 20161107 08:39:00< vultraz> but somehow it works in certain widgets 20161107 08:39:02< vultraz> like the text box 20161107 08:39:12< JyrkiVesterinen> Text box does use label_. 20161107 08:39:13< vultraz> maybe that has a label.. 20161107 08:39:17< vultraz> I see 20161107 08:39:25< vultraz> ... well, this is rather ridiculous, then :/ 20161107 08:39:42< JyrkiVesterinen> Indeed, this is a complete mess. :( 20161107 08:39:43< vultraz> only widgets with labels consider keys made available to all widgets :| 20161107 08:39:55< vultraz> can you fix it? 20161107 08:40:38< vultraz> (plus, even if it DOES have a label, it shouldn't just use min.. it should try default, and then try again with min if it doesn't fit...) 20161107 08:40:40< vultraz> blah. 20161107 08:40:50< vultraz> just use default, I mean 20161107 08:42:18< vultraz> then again, how should default size interact with grow factors.. 20161107 08:42:34< vultraz> I guess if _grow is specified as true, it should clamp size to min/max 20161107 08:42:39< vultraz> else use default 20161107 08:42:53< vultraz> or, should it try default first, then grow.. 20161107 08:42:55< vultraz> :/ 20161107 08:43:06< vultraz> wait, no, that'd be min... 20161107 08:43:15< JyrkiVesterinen> Growing is handled by tgrid. 20161107 08:43:49< JyrkiVesterinen> Tgrid simply sets every child element to the preferred size (get_best_size()) and distributes any remaining space beased on grow factors. 20161107 08:43:54< JyrkiVesterinen> *based 20161107 08:44:40< vultraz> blah :/ 20161107 08:44:57< JyrkiVesterinen> Tgrid doesn't ask widgets for their maximum sizes (in other words, it completely ignores maximum sizes). 20161107 08:45:25< vultraz> well, then how would one best utilize these min/default/max keys 20161107 08:45:46< vultraz> you could easily the size to min/max, I suppose.. 20161107 08:45:56< vultraz> easily clamp 20161107 08:46:14< vultraz> but it seems to me that the grid should try its best to fit widgets in a window 20161107 08:46:29< vultraz> so if they don't fit, try again with min size, or something.. 20161107 08:46:33-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20161107 08:46:39< vultraz> but then, how to handle default... 20161107 08:47:07< vultraz> max(best_size, default)? 20161107 08:47:19< JyrkiVesterinen> I think that at least textbox uses maximum width simply as the maximum size the textbox can *request*. 20161107 08:47:40< vultraz> well, that makes sense.. 20161107 08:47:44< JyrkiVesterinen> In other words, no matter how much text the box has, its get_best_size().x never exceeds the maximum width. 20161107 08:48:12< vultraz> this is complicated :| 20161107 08:48:22< vultraz> I trust you'll come up with something, though. 20161107 08:48:25< JyrkiVesterinen> It is quite reasonable use for maximum size IMHO, although likely not what the widget author would expect. 20161107 08:48:45< JyrkiVesterinen> I don't want to change too much. The risk of regressions is too high. 20161107 08:48:48< vultraz> yes, it is reasonable 20161107 08:49:06< vultraz> well, the current system feels rather incomplete 20161107 08:49:24< vultraz> so I think that's acceptable 20161107 08:49:39< JyrkiVesterinen> It *is* incomplete, since mordante didn't finish it. 20161107 08:49:56< JyrkiVesterinen> I'd like to follow his original design instead of coming up with my own. 20161107 08:50:26< JyrkiVesterinen> (If I were to design GUI2, I'd indeed have done some things differently, especially in layout handling.) 20161107 08:50:43< vultraz> well, I'd just like to be able to use these keys for the unit preview pane 20161107 08:51:12< vultraz> since they'd be perfect to say 'try this size, but you can go smaller if it doesn't fit well 20161107 08:51:26< vultraz> then again, since windows have scrollbars, I don't know if that's possible... 20161107 08:51:42< vultraz> since it essentially gives the widgets unlimited space to grow 20161107 08:52:21< wedge009> vultraz: Thanks for closing a bunch of bug reports. Did we have a release or were you just catching up? 20161107 08:52:30< vultraz> wedge009: yes, we had a release 20161107 08:53:20< JyrkiVesterinen> IIRC, tscrollbar_container actually asks its content to shrink in its request_reduce_* functions before turning on the scrollbars. 20161107 08:54:11< JyrkiVesterinen> I actually don't understand how scrollbars can work at all with that design. They do work, but I haven't debugged the code to understand how it works. 20161107 08:54:45< wedge009> Okay, thanks. 20161107 08:58:20-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV] 20161107 09:09:28-!- boucman_work [~boucman@fw-alt.idf.smile.fr] has quit [Ping timeout: 268 seconds] 20161107 09:13:42< irker539> wesnoth: Wedge009 wesnoth:master 800007844356 / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Removing recently-deleted SDL files from VC project. https://github.com/wesnoth/wesnoth/commit/800007844356e77f4be69ccded3e4ad9bd1f90e0 20161107 09:14:04< wedge009> Wow, first part of the hash is all numbers. 20161107 09:32:45< loonycyborg> vultraz: files.wesnoth.org/releases 20161107 09:44:50-!- travis-ci [~travis-ci@ec2-54-162-239-60.compute-1.amazonaws.com] has joined #wesnoth-dev 20161107 09:44:51< travis-ci> wesnoth/wesnoth#11911 (master - 8000078 : Wedge009): The build is still failing. 20161107 09:44:51< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173836287 20161107 09:44:52-!- travis-ci [~travis-ci@ec2-54-162-239-60.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161107 10:03:01-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161107 10:19:20-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV] 20161107 10:20:15< irker539> wesnoth: Wedge009 wesnoth:master 6cfe8b100cf4 / data/campaigns/Heir_To_The_Throne/utils/httt_utils.cfg: Spelling correction: Stangely -> Strangely https://github.com/wesnoth/wesnoth/commit/6cfe8b100cf41a71059f4eed930d3c2c7e3459f9 20161107 10:20:46< vultraz> D: 20161107 10:20:48< vultraz> a commit 20161107 10:27:43-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has joined #wesnoth-dev 20161107 10:31:10< vultraz> shadowm, loonycyborg: this was fixed a long time ago, right? https://gna.org/bugs/?24210 20161107 10:31:26< irker539> wesnoth: Charles Dang wesnoth:master b70200c8f5ce / src/sdl/ (rect.cpp rect.hpp): Attempt to fixup aa96353dfaaf https://github.com/wesnoth/wesnoth/commit/b70200c8f5ce2c73d445fcaea269d198f6af834b 20161107 10:31:29< irker539> wesnoth: Charles Dang wesnoth:master b739bdde2a4e / src/ (7 files in 3 dirs): Cleaned up SDL_Version.h includes https://github.com/wesnoth/wesnoth/commit/b739bdde2a4e5de62f73c3e18d429f34b97ec56d 20161107 10:33:01< JyrkiVesterinen> vultraz: I think b70200c8 won't build with MSVC2013. It doesn't support constexpr, and thus I expect that defining empty_rect in rect.hpp violates the One Definition Rule. 20161107 10:33:14< vultraz> :| 20161107 10:36:56< vultraz> this lack of proper constexpr support is rather annoying 20161107 10:39:41< vultraz> since it essentially means we can only use constexpr for functions and not constants 20161107 10:51:12-!- travis-ci [~travis-ci@ec2-54-167-132-6.compute-1.amazonaws.com] has joined #wesnoth-dev 20161107 10:51:14< travis-ci> wesnoth/wesnoth#11912 (master - 6cfe8b1 : Wedge009): The build is still failing. 20161107 10:51:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173850140 20161107 10:51:14-!- travis-ci [~travis-ci@ec2-54-167-132-6.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161107 11:02:21< loonycyborg> vultraz: yes 20161107 11:16:24-!- travis-ci [~travis-ci@ec2-54-167-81-45.compute-1.amazonaws.com] has joined #wesnoth-dev 20161107 11:16:24< travis-ci> wesnoth/wesnoth#11913 (master - b739bdd : Charles Dang): The build was fixed. 20161107 11:16:25< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/173852747 20161107 11:16:25-!- travis-ci [~travis-ci@ec2-54-167-81-45.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161107 11:36:47< vultraz> zookeeper: can you fix this? https://gna.org/bugs/?22917 20161107 11:37:09< vultraz> zookeeper: the problem is that bridges draw on the dwarven castle -> chasm transition 20161107 11:37:12< vultraz> er 20161107 11:37:16< vultraz> s/on/under 20161107 11:37:30< zookeeper> umm. maybe. 20161107 11:37:37< zookeeper> will look 20161107 11:38:09< vultraz> line 729 20161107 11:39:13< vultraz> though I'm confused, since it also seems to set up chasm transitions on line 750 20161107 11:39:16< vultraz> which is on -89 20161107 11:39:23< vultraz> and Bsb is on -80 20161107 11:39:52< vultraz> while you're at it, maybe you can make Chasm Bridges work like the other bridges.. 20161107 11:40:09< vultraz> Chasm bridges do not have the problem since they're treated as overlays 20161107 11:40:23< vultraz> (407, OVERLAY_F) 20161107 11:40:44< vultraz> while other bridges use BRIDGE:STRAIGHTS 20161107 11:41:29< vultraz> anyway, I know it's specifically a layering problem since if you overlay the base with grass, the bridge end appears drawn under the castle 20161107 11:41:32< vultraz> which is desirable 20161107 11:42:03< vultraz> hmm 20161107 11:42:09< vultraz> actually, it seems to affect any castle 20161107 11:42:21< vultraz> so it seems any castle -> chasm transition drawn over the bridges 20161107 11:42:47< vultraz> but again, not a problem for chasm bridges 20161107 11:43:01< vultraz> but it'd be better to make them behave like the rest, since now they draw *over* castle walls 20161107 11:43:03< vultraz> which looks weird 20161107 11:44:27< vultraz> zookeeper: so, tl'dr, bridges are drawn under castles, except the chasm bridge, but castle -> chasm transitions draw over bridges. 20161107 12:07:49< irker539> wesnoth: Charles Dang wesnoth:master be8eb90d2f23 / data/core/macros/abilities.cfg: Clarify wording of Heals abilities regarding poisoned units (bug #22945) https://github.com/wesnoth/wesnoth/commit/be8eb90d2f230484f75abfa3cdd7a9859b1da228 20161107 12:07:55< vultraz> zookeeper: ^ 20161107 12:09:19< zookeeper> looks ok 20161107 12:10:45-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161107 12:20:00< vultraz> wedge009: have you been closing bugs in the past few hours? 20161107 12:20:36< wedge009> Mostly. Is this bad? I'm leaving ones I'm still not sure about. 20161107 12:21:01< vultraz> nah 20161107 12:21:11< vultraz> just wondered why the issue count had suddenly dropped :P 20161107 12:21:23< vultraz> ive been going through old entries myself 20161107 12:21:28< vultraz> closing some stuff that's no longer valid 20161107 12:21:41< vultraz> and i just realized, most of the early entries are all feature requests 20161107 12:21:59< vultraz> there's only like 277 bugs 20161107 12:22:11< vultraz> so a little less than 2/3 of the remaining issues are FRs :D 20161107 12:22:40< wedge009> There were a ton of reports added in the last few months. 20161107 12:22:51< wedge009> We were below 300 for the last release too, I think. 20161107 12:24:07< vultraz> still, we've also closed a lot over the past few months 20161107 12:24:16< vultraz> the overall total has gone down 20161107 12:24:21< vultraz> despite the submissions 20161107 12:28:49< vultraz> zookeeper: duplicate of the other chasm thing. feel free to mark both as fixed if you get a fix . https://gna.org/bugs/?18873 20161107 12:29:08< vultraz> also, see if you want to close this https://gna.org/bugs/?18866 20161107 12:31:12-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has quit [Ping timeout: 252 seconds] 20161107 12:36:21-!- gfgtdf [~chatzilla@x4e36a8b5.dyn.telefonica.de] has joined #wesnoth-dev 20161107 12:43:27< wedge009> If checking hex transitions, maybe this one is also worth reviewing? https://gna.org/bugs/?22917 20161107 12:47:18< gfgtdf> i wonder whether we could add a 'effcts 1.12 only' tag/sttus to our bugtracker (i was hoping that we dont need it since wanted to move to a new bugtracker soon but this doesn'T seem to be the case) 20161107 12:48:05< vultraz> wedge009: yeah i linked him that earlier 20161107 12:48:19< vultraz> gfgtdf: still hoping to get the tracker thing done 20161107 12:49:22< wedge009> So you did. Sorry about that. 20161107 13:17:21-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV] 20161107 13:17:48-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009] 20161107 13:18:09-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20161107 13:20:36< zookeeper> vultraz, wedge009, the bridge<->dwarvencastle thing is basically too difficult to fix in any kind of simple way, so at least for now i'm just letting it be 20161107 13:37:13-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev 20161107 14:47:27< tad_carlucci> loonycyborg, In re commit b1d110b95eb941e921c82ddd9577a1d5e4048bc0 from 14SEP2016 "Remove old networking stack" I'm examining src/tests/test_network_worker.cpp which depends upon src/network_worker.hpp deleted by the commit. Should the test be removed? 20161107 14:49:01< loonycyborg> if it's not used then yes 20161107 14:49:12< loonycyborg> somehow I thought 20161107 14:49:19< loonycyborg> I deleted it 20161107 14:49:28< tad_carlucci> OK. I'm noting it and will get to it if you don't 20161107 14:51:37< tad_carlucci> That will delete: src/tests/test_network_worker.cpp src/tests/utils/predicate.hpp src/thread.cpp and src/thread.hpp 20161107 14:53:39< loonycyborg> what was thread.cpp used for? 20161107 14:55:04< shadowm> The SDL_net network API surely. 20161107 14:55:05< gfgtdf> for woker threads in the old network code 20161107 14:55:52< tad_carlucci> At thos point the only reference is from the zombie 20161107 14:56:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161107 14:59:49< loonycyborg> ok 20161107 15:01:47-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161107 15:02:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds] 20161107 15:07:55-!- irker539 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161107 15:18:32< tad_carlucci> loonycyborg, Adding more to the list not removed by that commit. It may be another day or so before I'm sure I have them all. I'll let you know when I have the PR up. 20161107 15:18:46< loonycyborg> ok 20161107 15:30:20-!- stikonas_ is now known as stikonas 20161107 15:32:47-!- gfgtdf [~chatzilla@x4e36a8b5.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]] 20161107 15:37:41-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161107 15:42:08-!- kidneb [kidneb@2a01:7e00::f03c:91ff:fe33:363c] has quit [Ping timeout: 245 seconds] 20161107 15:43:34-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has quit [Quit: .] 20161107 15:48:56< vultraz> zookeeper: but what about the other castles <-> bridges 20161107 15:49:09< zookeeper> well, same thing really... i think 20161107 15:50:30< vultraz> not really 20161107 15:50:39-!- kidneb [kidneb@2a01:7e00::f03c:91ff:fe33:363c] has joined #wesnoth-dev 20161107 15:50:43< vultraz> other castles don't have parts of themselves baked into the transition images 20161107 15:55:45< vultraz> blagh, now the other castles seem to work? 20161107 15:55:49 * vultraz throws up hands 20161107 16:03:16-!- irker093 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161107 16:03:17< irker093> wesnoth: ln-zookeeper wesnoth:master f9e36df15587 / data/core/images/terrain/castle/aquatic-camp/ (keep-tile.png reef-big.png reef.png reef2.png reef3.png reef4.png): Aquatic camp image tweaks https://github.com/wesnoth/wesnoth/commit/f9e36df1558753be2cd3dedabdf0b9dfbb6a268b 20161107 16:06:19< zookeeper> in theory all the castle walls could be made to mesh together nicely without those encampment walls filling in the gaps, but it might be too awkward to actually do... 20161107 16:10:34-!- boucman_work [~boucman@fw-alt.idf.smile.fr] has joined #wesnoth-dev 20161107 16:29:31-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20161107 16:32:08< vultraz> celticminstrel: so i found this ancient FR regarding right click behavior on macOS: https://gna.org/bugs/?9151 20161107 16:32:29< vultraz> celticminstrel: im wondering if we should add right click handling? 20161107 16:33:36< celticminstrel> Is that really Mac-specific? 20161107 16:34:09< vultraz> no 20161107 16:34:55< celticminstrel> There is a Mac thing though - Ctrl-click should really be equivalent to right-click on the Mac. 20161107 16:37:29< vultraz> right now we specifically only handle left clicks in dropdown 20161107 16:37:45< vultraz> but right click handling only makes sense if invoked as a context menu 20161107 16:37:56< vultraz> not as a dropdown menu menu 20161107 16:39:46< vultraz> wedge009: i believe you tested this back in august? https://gna.org/bugs/?22324 20161107 16:48:28< vultraz> zookeeper: ftr jet said it's very likely he'll get more desert elf sprites done for 1.14 20161107 16:50:16< vultraz> celticminstrel: still a problem? https://gna.org/bugs/index.php?24578 20161107 16:50:58< celticminstrel> Don't ask me. Ask ancestral or mattsc. 20161107 16:51:07< celticminstrel> It's impossible for me to test that. 20161107 16:51:08< vultraz> oh right, you don't have notifs.. 20161107 16:51:20< vultraz> where is ancestral anyway :/ 20161107 16:51:20< zookeeper> vultraz, uh, okay. 20161107 16:51:30< celticminstrel> No idea. 20161107 16:54:25< vultraz> bahahahahaha https://gna.org/bugs/?22485 20161107 16:55:20< vultraz> I guess I can do that, though 20161107 16:56:40< zookeeper> i wouldn't take poorly justified report as evidence that there really is a legitimate need which isn't so scenario-specific that it can't just be hardcoded in the scenario. 20161107 16:56:46< zookeeper> +such a 20161107 16:57:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161107 16:57:14< vultraz> true 20161107 16:57:19< vultraz> maybe ill just mark Won't Fix 20161107 16:57:21< zookeeper> well, i guess the "should increase if the scenario has a side with more the 800 startgold or 18 income" part is reasonable 20161107 16:57:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161107 16:57:42< vultraz> celticminstrel: iirc this was fixed? https://gna.org/bugs/?22828 20161107 16:57:43< zookeeper> implementing that wouldn't really have any downsides, so... 20161107 16:57:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161107 16:58:26< vultraz> i seem to remember the generator failing when i was working on the settings dialog and it didn't crash.. I think 20161107 16:59:16< vultraz> celticminstrel: oh, and can you confirm if this is still an issue (mac-specific) https://gna.org/bugs/?21943 20161107 17:01:18< celticminstrel> I have no idea if the generator issue was fixed. 20161107 17:02:40< celticminstrel> Last I checked, fullscreen on Mac uses the special fullscreen mode which fills the other monitor with a matte background. 20161107 17:03:01< celticminstrel> (Though maybe it has improved since 10.7 and no longer does that, I dunno.) 20161107 17:04:10< celticminstrel> I haven't tested whether app switching works from fullscreen mode... I'd expect it to, though... 20161107 17:04:51< DeFender1031> better than fullscreen on debian kde with mutiple monitors... THAT just blows up my display completely 20161107 17:05:34< DeFender1031> that was also compounded with a bug i found where if you clear a default hotkey, it'll reset to default next time you start up. 20161107 17:07:20< DeFender1031> and since ctrl-f is used for "find" in everything else, i accidentally blew up my display while thinking a different window had focus and had to restart several times before i finally realized that the only way to make the hotkey not come back was to assign ctrl-f to some other action. 20161107 17:07:49< celticminstrel> You could rebind Ctrl+F to find in Wesnoth too, if that helps. 20161107 17:08:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20161107 17:09:08< DeFender1031> by "blew up display" I mean it killed half my panels, the others that remained ended up all on my primary moditor along with all windows of all applications, and the desktop environement itself was unresponsive, the panels unclickable, etc. 20161107 17:09:21< celticminstrel> Whoa 20161107 17:09:24< DeFender1031> celticminstrel, i think that's what i did 20161107 17:10:16< DeFender1031> IIRC, keyboard shortcuts for switching applications and virtual desktops still worked after the blow up though, but everything else was shot 20161107 17:10:26< DeFender1031> and yeah, "Whoa" is right 20161107 17:11:04< DeFender1031> yeah, i remapped ctrl-f to "Find Label or Unit" 20161107 17:11:47< DeFender1031> anyway, i use kde's fullscreening to make wesnoth play in fullscreen, since using its internal one does all what i said above. 20161107 17:12:12< DeFender1031> once i get set up to compile dev, i'll let you guys know if it's still an issue, because if it is, it's a MAJOR issue. 20161107 17:12:35< celticminstrel> I wouldn't be surprised if it's fixed because of SDL2. 20161107 17:13:35< DeFender1031> right, nor would i 20161107 17:14:25< DeFender1031> that's the other thing, I didn't report it because i have no way of knowing if it's a bug with KDE, SDL, wesnoth, or simply the interaction between the three with no single one of them having a specific bug 20161107 17:14:58< DeFender1031> oh... could also be an issue with X for all i know... or with NVidia's drivers... 20161107 17:15:35< celticminstrel> Why does everyone have to call the variables by the same name as the type... 20161107 17:15:48< celticminstrel> There's tons of "txyzw xyzw" around. 20161107 17:16:18< DeFender1031> celticminstrel, what else are you going to call them? 20161107 17:16:47< celticminstrel> Maybe something indicating what they're for, rather than what they are? 20161107 17:16:51< DeFender1031> This is part of the reason why I like caps for types 20161107 17:16:59< celticminstrel> Yeah. 20161107 17:17:03< DeFender1031> that certainly works sometimes 20161107 17:17:36< DeFender1031> but in many cases, the variable is just the entity of that type that this function is working with 20161107 17:17:52< celticminstrel> ...argh, I accidentally cleared my terminal scrollback. >< 20161107 17:18:09< DeFender1031> i did that yesterday by mistake 20161107 17:18:22< vultraz> HAH 20161107 17:18:28< celticminstrel> Why is vultraz laughing 20161107 17:18:29< vultraz> i'm screwing up gui2 20161107 17:18:30< DeFender1031> (I killed the hotkey for clearing my saved logs a long time ago after one too many such mishaps) 20161107 17:18:40< DeFender1031> [11/7/2016 7:47:54 pm] that certainly works sometimes 20161107 17:18:41< DeFender1031> [11/7/2016 7:48:27 pm] but in many cases, the variable is just the entity of that type that this function is working with 20161107 17:18:43< DeFender1031> [11/7/2016 7:48:43 pm] ...argh, I accidentally cleared my terminal scrollback. >< 20161107 17:19:05< celticminstrel> vultraz: ??? 20161107 17:19:22< vultraz> celticminstrel: attempting to fix a weird-ass bug with linked groups 20161107 17:19:43< celticminstrel> Sounds like something that'll conflict with the rename. 20161107 17:20:05< DeFender1031> anyway, i was saying that for example, take a simple function that takes a unit and returns the percentage of the unit's health remaining. You could call the variable "toGetPercentageFrom", but that's long and unweildy... more intuitive to just call it "unit". 20161107 17:20:17< DeFender1031> but if unit is also a type, you end up with issues. 20161107 17:20:23< vultraz> i don't know what I'm doing anyway :P 20161107 17:26:52< vultraz> there's this really weird bug where if i make the icons and name align in mp create 20161107 17:27:12< vultraz> switching from campaigns to scenarios or something seems to cause layout invalidation 20161107 17:27:17< vultraz> and random things change size 20161107 17:27:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161107 17:36:44< tad_carlucci> You know all the questioing of whether anyone objects to removing src/gettext.cpp and libintl and the answer is, "Why bother, it won't compile, anyway, unless someone fixes the logging #defines" 20161107 17:37:10< shadowm> We know. 20161107 17:37:19< DeFender1031> vultraz, https://xkcd.com/1700/ 20161107 17:37:44< tad_carlucci> Well, I'm fixing them locally because it's in my way. :O 20161107 17:37:57< celticminstrel> It's easy, just add () 20161107 17:38:02< tad_carlucci> Yep 20161107 17:41:18< vultraz> god dammit gui2 20161107 17:41:21< vultraz> what are you doing 20161107 17:44:04< celticminstrel> It's conspiring against you! 20161107 17:45:17< vultraz> when the grow factor is 0, the stuff aligns, but there's weird size changes in the right column 20161107 17:45:19< vultraz> but if it's 1 20161107 17:45:40< vultraz> the size change of the list is less, and there are no side changes in the right column, but one category doesn't line up 20161107 17:45:46< vultraz> *what is this bullshit* ;_; 20161107 17:46:18< vultraz> i'll just have to wait for jyrki's size lock 20161107 17:47:10< celticminstrel> vultraz: Do you have a better name for timage? 20161107 17:47:39< celticminstrel> If I just call it image, then I need "::image" to reference the image resolution and modification stuff. 20161107 17:48:00< celticminstrel> eg, "image::exists(...)" becomes "::image::exists(...)". 20161107 17:49:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds] 20161107 17:50:44< vultraz> image_widget? 20161107 17:50:46< vultraz> idk 20161107 17:51:48< celticminstrel> I suppose... not happy with that name, but there's stacked_widget already so I guess it's okay. 20161107 17:51:59< celticminstrel> Should I go with that then? 20161107 17:52:56< vultraz> up to you 20161107 17:53:01 * vultraz out 20161107 17:56:39< tad_carlucci> celticminstrel, No, it's not easy. I have a choice: do what SCons/CMake to and skip gettext_boost leading to link errors or include it leading to link errors. *sigh* 20161107 17:57:10< celticminstrel> tad_carlucci: Copying compare and icompare into gettext.cpp should help with that. 20161107 17:57:33< celticminstrel> Not entirely sure if they're the only problem though. 20161107 17:59:47< tad_carlucci> strftime and compare 20161107 18:00:00< celticminstrel> Right... 20161107 18:00:39< celticminstrel> I don't suppose you have a better name for an image widget class BTW? 20161107 18:02:34< tad_carlucci> I like "image" if it's just a image file. But I supposeyou could call it 'picture' or 'portait' or 'icon' 20161107 18:02:52< celticminstrel> Hmm. 20161107 18:03:10< celticminstrel> It's weird to change the name without changing the WML tag, but I guess that can be done in two steps. 20161107 18:03:16< DeFender1031> visual_data_item 20161107 18:03:22< celticminstrel> Blech. 20161107 18:03:36< DeFender1031> arranged_collection_of_pixels 20161107 18:03:55< celticminstrel> ... 20161107 18:03:59< DeFender1031> pretty_thing_to_look_at_on_the_screen_cowfish 20161107 18:04:24< DeFender1031> <--- not helping. 20161107 18:05:06< DeFender1031> seriously though, not sure why "image" isn't a good name. 20161107 18:05:17< tad_carlucci> tired of cowfish .. how about from todays newsfeed: twoHeadedShark 20161107 18:05:22< celticminstrel> It's a great name. 20161107 18:05:40< celticminstrel> But there's a namespace (IIRC) with the same name. 20161107 18:05:55< celticminstrel> So if I stick with image, I need to write ::image in some cases. 20161107 18:05:56< DeFender1031> tad_carlucci, deal. 20161107 18:06:10< celticminstrel> Which isn't a huge deal, I guess. 20161107 18:07:03< tad_carlucci> image as a class representing an image file sounds good. image as a namespace makes me wonder if the namespace needs renaming 20161107 18:07:23< DeFender1031> what's IN that namespace? 20161107 18:07:33< celticminstrel> It's stuff to do with image loading and manipulation and stuff. 20161107 18:07:58< tad_carlucci> so rename it to namespace image_manipulation 20161107 18:08:16< celticminstrel> And image mods are in that namespace too. 20161107 18:08:35< tad_carlucci> image_utilities 20161107 18:08:40< celticminstrel> Hmm. 20161107 18:08:42< celticminstrel> Well, maybe. 20161107 18:08:55< celticminstrel> I'll stick with image for the class then. 20161107 18:08:58< DeFender1031> yeah 20161107 18:09:03< celticminstrel> Might rename the namespace later. 20161107 18:09:04< DeFender1031> that'd be my suggestion too 20161107 18:09:52< celticminstrel> It'd be so convenient if clang could actually apply its suggestions directly to my source code. 20161107 18:10:11< celticminstrel> (Admittedly, sometimes the suggestions are wrong though.) 20161107 18:12:53< DeFender1031> hmm... why DON'T compilers have such a feature? 20161107 18:13:14< DeFender1031> i mean, it certainly shouldn't happen by default 20161107 18:13:36< celticminstrel> clang gives nice suggestions, at least (that's why I like it so much). 20161107 18:13:38< DeFender1031> but there are certain things that a compiler should be smart enough to automatically apply if you tell them to 20161107 18:13:55< celticminstrel> And I think it usually applies those suggestions internally in its attempt to recover and continue. 20161107 18:13:55< DeFender1031> true, but it's also got a lot of strange bugs 20161107 18:14:00< celticminstrel> Like what? 20161107 18:14:14< celticminstrel> Ack I forgot to save a source... 20161107 18:14:20< celticminstrel> Hopefully I made it in time... 20161107 18:15:42< DeFender1031> a coworker of mine encountered a case a few days ago where there were two loops, one which builds up a vector of stuff and also initializes some variable and the other which loops through it and uses that variable, and it was giving an error about a possibly uninitialized variable even though the second loop could only be entered if the first one was also run at least once 20161107 18:16:06< DeFender1031> let me see if i can A: dig it up and B: am authorized to share it 20161107 18:16:18< celticminstrel> Well, that's a warning though, not an error. 20161107 18:17:22< DeFender1031> still, compilers shouldn't warn about things that can't happen 20161107 18:18:00< DeFender1031> anyway: http://i.imgur.com/yF689Eu.png and http://i.imgur.com/4XDXQxu.png 20161107 18:18:19< DeFender1031> he's also told me of times when it actually encountered errors which weren't actually errors 20161107 18:18:56-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev 20161107 18:19:04< celticminstrel> That second screenshot looks like the static analyzer? 20161107 18:19:28< DeFender1031> there's no way for the second loop condition to be true if the first was false 20161107 18:19:29< celticminstrel> Both do, in fact. 20161107 18:20:08< DeFender1031> i suppose? 20161107 18:20:34< celticminstrel> Is running the static analyzer as a matter of course normal? I've only run it occasionally on my code. 20161107 18:20:40< celticminstrel> (I don't think I ever ran it on Wesnoth.) 20161107 18:20:44< DeFender1031> no idea 20161107 18:21:09< celticminstrel> Well, erroneous reports from that seem less problematic than erroneous errors or warnings from the compiler... 20161107 18:21:33< DeFender1031> fair enough, but i know he's had times where it wouldn't compile valid code 20161107 18:26:31< tad_carlucci> OK. gettext.cpp is fixable, it passed my checks with some copy-n-paste fromm gettext_boost, so I can back out my changes since it's going away. 20161107 18:30:46-!- boucman_work [~boucman@fw-alt.idf.smile.fr] has quit [Read error: Connection reset by peer] 20161107 18:32:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161107 18:37:38-!- astrelyon [~astrelyon@78.134.238.157] has joined #wesnoth-dev 20161107 18:38:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds] 20161107 18:43:16-!- JyrkiVesterinen [~jyrki@87-92-3-99.bb.dnainternet.fi] has joined #wesnoth-dev 20161107 18:58:24-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev 20161107 19:01:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161107 19:03:44-!- irker093 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161107 19:29:03< tad_carlucci> Who can speak about gui/widgets/list.?pp and GUI2_EXPERIMENTAL_LISTBOX ? It is missing a header: gui/widgets/details/register.hpp so won't compile. 20161107 19:29:55< celticminstrel> It's supposed to be a replacement for the GUI2 listbox. 20161107 19:30:18< celticminstrel> ie, it's supposed to replace listbox.hpp (at least partially if not fully). 20161107 19:30:28< tad_carlucci> I can see that. From 2010 by Mark de Wever 20161107 19:30:28< celticminstrel> I don't know all the details about it though. 20161107 19:30:35< celticminstrel> Ask mordante or vultraz. 20161107 19:30:44< celticminstrel> (mordante is presumable Mark de Wever) 20161107 19:30:58< celticminstrel> (^bly) 20161107 19:31:41< celticminstrel> I think one of the differences is that it's supposed to support not allowing a selected item. 20161107 19:33:11< tad_carlucci> What I'm doing is asking my build system to try every option it can and I'm down to the last few files in the src tree which I've not found referenced. I s'pose I can leave it alone, mark it to keep, and move on. 20161107 19:33:46< celticminstrel> Probably should be kept, yeah. 20161107 19:34:04< celticminstrel> vultraz wants it to be finished eventually, I think. 20161107 19:36:05< tad_carlucci> Well, it's missing a header so it's a lost cause at the moment unless it doesn't actually NEED that header. 20161107 19:37:34< tad_carlucci> I think I'm down to 3 files for the Windows console support, and what looks like an zombie at first glance: gui/auxiliary/iterator/iterator.cpp 20161107 19:38:25< celticminstrel> It's a zombie? 20161107 19:38:28< celticminstrel> How so? 20161107 19:40:18< celticminstrel> Oh, I think I get it. 20161107 19:40:29< celticminstrel> That iterator is a header-only class. 20161107 19:40:36< celticminstrel> But he documented it in the cpp. 20161107 19:41:22< celticminstrel> So basically iterator.cpp exists solely for the benefit of doxygen. 20161107 19:41:49< tad_carlucci> Got a couple of empty cpp files for header-only hpp. Probably why they're all there. 20161107 19:43:10< celticminstrel> I should probably read that file in more detail. 20161107 19:43:26< celticminstrel> While renaming things I came to the conclusion that twalker_ wasn't meant to be used directly. 20161107 19:43:33< celticminstrel> (Which surely will make vultraz happy. :P ) 20161107 19:43:54< celticminstrel> But was rather meant as in internal class used by the iterator. 20161107 19:44:08 * celticminstrel qualifies all that with "maybe". 20161107 19:44:18< tad_carlucci> Looks like that, to me, too. 20161107 19:59:23-!- JyrkiVesterinen [~jyrki@87-92-3-99.bb.dnainternet.fi] has quit [Quit: .] 20161107 20:00:15-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20161107 20:10:33-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Remote host closed the connection] 20161107 20:11:10-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161107 20:16:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161107 20:18:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit] 20161107 20:19:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161107 20:23:09-!- Ivanovic_ [~ivanovic@p579FBF3F.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161107 20:23:09-!- Ivanovic_ [~ivanovic@p579FBF3F.dip0.t-ipconnect.de] has quit [Changing host] 20161107 20:23:09-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20161107 20:23:18-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Write error: Broken pipe] 20161107 20:24:14< tad_carlucci> celticminstrel, src/formula/callable_fwd.hpp is from 2008, is never used and has no .cpp .. should it be eliminated? 20161107 20:24:43< celmin> Good question! 20161107 20:25:07-!- Ivanovic_ is now known as Ivanovic 20161107 20:25:15< celmin> It's theoretically a forwarding header for src/formula/callable.hpp so that places don't need to include the full definition… no idea if that's needed though. 20161107 20:37:08< tad_carlucci> celmin, I can assure you it's not referenced by code (which is how I found it). 20161107 20:37:30< celmin> I believe you. 20161107 20:37:44< celmin> I wonder if it can be substituted for any instances of callable.hpp though. 20161107 20:37:50< celmin> (Only in headers of course.) 20161107 20:38:10< tad_carlucci> celmin, No harm to leave it there. I'll mark it to keep. Might help in the future. 20161107 20:43:31< vultraz> tad_carlucci: GUI2_EXPERIMENTAL_LISTBOX was an ambition WIP project to design a new list widget 20161107 20:43:38< vultraz> mordante never finished it 20161107 20:43:51< tad_carlucci> vultraz, Keep or delete? 20161107 20:44:00< vultraz> keep 20161107 20:44:08< tad_carlucci> OK. TY. 20161107 20:44:28< vultraz> tad_carlucci: one thing you can remove is LOW_MEM :P 20161107 20:45:21< tad_carlucci> OK. Adding it to my list. I didn't see it because it didn't effect which source/header files we use. 20161107 20:45:34< tad_carlucci> I'm running through the easy stuff for PRs now. 20161107 20:45:37< vultraz> though most cases have been removed by now and more will go as soon as celmin commits he rename 20161107 20:45:52< vultraz> the* 20161107 20:47:06< tad_carlucci> The test runs are taking way longer than the changes. Add a line for CMake. Wade through a rebuild even though I know it'll work. Check it runs even though I know it will. Push up the PR .. still waiting for the build. 20161107 20:51:20< vultraz> why do you rebuild? 20161107 20:51:25< vultraz> instead of just building :/ 20161107 20:51:50< vultraz> and celticminstrel, how's that rename coming along 20161107 20:54:01< celmin> Still working through errors from the widget rename. 20161107 20:54:03< tad_carlucci> vultraz, I am 'just building' but the last branch was that monster for all the includes and other little issues and so it's virtually rebuilding all. 20161107 20:54:11< celmin> Looks to be almost done though. 20161107 20:54:13< vultraz> ah 20161107 20:54:19< celmin> Then I need to rename dialogs and aux classes. 20161107 20:54:24< vultraz> :| 20161107 20:54:31< celmin> Plus some internal classes for the widgets. 20161107 20:54:33< celmin> eg tvisible 20161107 20:54:33< vultraz> :| 20161107 20:54:36< vultraz> :| 20161107 20:54:41< celmin> Why so much :| 20161107 20:54:43< tad_carlucci> celmin, I took a quick look at eliminating libintl / gettext.cpp and I feel for you. 20161107 20:54:47< vultraz> ok, I'll expect it tomorrow, then 20161107 20:55:16< celmin> I think it could be done today, but not sure. Definitely can be done tomorrow. 20161107 20:55:38< celmin> Renaming the dialogs probably will be a lesser chore compared to renaming the widgets - they're used in fewer places. 20161107 20:55:45< celmin> aux could be annoying though 20161107 20:56:42< tad_carlucci> My dev tool as a nice solution for all that. When I realize it's massive and I don't want to do it after all. "Revert all changes." One button and I'm done. 20161107 20:57:47< celmin> "git reset --hard" :P 20161107 20:57:51< celmin> (Or "git checkout src" 20161107 20:57:52< celmin> ) 20161107 20:58:09< tad_carlucci> Yep. I think that's how the button works. 20161107 20:58:09< celmin> (Which works great if everything you don't want to undo has been staged and everything you do want to undo has not been staged.) 20161107 20:58:48< vultraz> not to rush you or anything, it's just that i can't merge tad's prs or work on dropping the gui1 mo stuff until it lands. 20161107 21:00:00< tad_carlucci> The lua cleanup PR is done and safe to merge now. I'd wait in the 'lot of little' PR because I have a feeling it's going to conflict once Celmin's done 20161107 21:00:17< celmin> There was a Lua cleanup PR? 20161107 21:00:48< tad_carlucci> Deleting two files and updatingthe projects and .md .. we do NOT want to EVER allow ANYONE to accidentially use the files. 20161107 21:01:01< celmin> ?? 20161107 21:01:31< tad_carlucci> One re-initialzes the environment. The other causes link errors out the ying-yang 20161107 21:01:58< celmin> ...? 20161107 21:02:28< tad_carlucci> We compile using C++ .. lua.hpp looks tempting but forces "C" linkage. 20161107 21:03:21< tad_carlucci> And linit() pulls in all the lua libraries we don't want and wipes out some of our other stuff. Neither presently used but safer to not have the around, just in case. 20161107 21:08:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161107 21:09:01-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161107 21:17:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161107 21:19:45-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Remote host closed the connection] 20161107 21:21:43< shadowm> tad_carlucci: Wasn't the main point of your work on upgrading us to Lua 5.3 to have as few differences from upstream as possible? 20161107 21:21:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds] 20161107 21:28:38< tad_carlucci> Sure but rm is an easy thing to do and there's no point either compiling the lua interpreter, or compiler, or leaving cruft where a future programmer can accidentially mess things up. So copy in everything, then delete 5 (Was 3) files. and it's done. 20161107 21:29:15< shadowm> And here I thought I was the one with the least faith in devs. 20161107 21:29:21-!- stikonas_ is now known as stikonas 20161107 21:30:39< tad_carlucci> shadowm, I have decades more practive being cynical about users and programmers than most here. 20161107 21:31:04< shadowm> I am aware of that. 20161107 21:32:15< tad_carlucci> What did we say: If you want it broken, as a user. To really mess things up, you need a programmer. 20161107 21:32:19< tad_carlucci> *ask 20161107 21:54:17-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV] 20161107 21:57:26-!- irker540 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161107 21:57:27< irker540> wesnoth: Gregory A Lundberg wesnoth:master c5f69a227dbc / src/CMakeLists.txt: CMake unit tests https://github.com/wesnoth/wesnoth/commit/c5f69a227dbcb44270bce9ffc88e11bdc0d1a25d 20161107 21:57:27< irker540> wesnoth: Charles Dang wesnoth:master 031c9cbaa9eb / src/CMakeLists.txt: Merge pull request #865 from GregoryLundberg/GL_missing_unit_test https://github.com/wesnoth/wesnoth/commit/031c9cbaa9eb1413b8737d38fd1bc33b2124b2a9 20161107 21:57:36< irker540> wesnoth: Gregory A Lundberg wesnoth:master 15b7f75b3cb6 / / (7 files in 3 dirs): Lua cleanup https://github.com/wesnoth/wesnoth/commit/15b7f75b3cb6089986c483572a58e986a66e15da 20161107 21:57:38< irker540> wesnoth: Charles Dang wesnoth:master 967e3d2ca61a / / (7 files in 3 dirs): Merge pull request #864 from GregoryLundberg/GL_Lua_cleanup https://github.com/wesnoth/wesnoth/commit/967e3d2ca61a7fdf4e33a8c91f0c7513eb9ca80a 20161107 21:59:42< vultraz> tad_carlucci: looks like your bunch of stuff pr won't conflict with celmin's stuff 20161107 21:59:54< celmin> What was the number again? 20161107 22:00:10< vultraz> https://github.com/wesnoth/wesnoth/pull/863/files 20161107 22:00:12< celmin> I renamed a bunch of non-GUI2 stuff too. 20161107 22:00:17< vultraz> as long as he didn't rename any files 20161107 22:00:24< vultraz> like he said he wouldn't 20161107 22:00:24< celmin> I didn't rename any files. 20161107 22:00:29< celmin> Pretty sure. 20161107 22:00:44< celmin> Might've early on... 20161107 22:00:57< tad_carlucci> Still, I'd prefer waiting and fixing my side than causing Celmin more trouble. 20161107 22:02:47< celmin> Does look unlikely to conflict, but it's also huge so I don't feel like combing through it right now. 20161107 22:26:35-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!] 20161107 22:30:26< zookeeper> vultraz, doing announcement soon? 20161107 22:30:40< vultraz> zookeeper: I'm waiting for ancestral 20161107 22:34:34< vultraz> he hasn't uploaded the macos package 20161107 22:44:23< Aginor> it'd be good to look into the md5 checksum issue at the same time 20161107 22:44:33< vultraz> and he's not here so i can't ask him about it 20161107 22:44:46< tad_carlucci> What md5 issue? 20161107 22:45:13< celticminstrel> The fact that uploading to SF.net inexplicably changed the checksum even though redownloading and comparing showed no differences. 20161107 22:45:17< vultraz> md5 hashes don't match between downloads and uploaded packages 20161107 22:45:32< tad_carlucci> Oh, that. 20161107 22:45:35< Aginor> tad_carlucci: there's been reports of md5 sum mismatches between ancestral's setup and the SF.net hosted packages 20161107 22:46:12< tad_carlucci> I remember not too long ago it was tested and heads were scratched over it. 20161107 22:49:13< Aginor> tad_carlucci: we never got to the bottom over it due to ancestral not being able to find his original 20161107 22:49:33< Aginor> I also wonder whether it'd be wortwhile to zip the .dmg as well, so it's a dmg.gz 20161107 22:53:00< vultraz> no 20161107 22:53:57< celticminstrel> Aginor: dmg is already compressed. 20161107 22:54:01< celticminstrel> So probably not worth it. 20161107 22:54:10< celticminstrel> (It's a compressed disk image, to be precise.) 20161107 22:55:05< vultraz> You would confuse more people with a zipped dmg with with a hash mismatch 20161107 22:55:29< vultraz> s/with with/than with 20161107 22:56:06< celticminstrel> Aginor: I distinctly recall ancestral comparing to the original as I said before, when he first uploaded and discovered it. 20161107 22:56:21< celticminstrel> Then not too long ago it came up again. 20161107 22:56:52< celticminstrel> Perhaps by then he had lost the original to compare, but I'm pretty sure he had already gone through all that the first time. 20161107 22:57:38< vultraz> celticminstrel: did you ever confirm that trackpad issue? 20161107 22:57:55< celticminstrel> No, I didn't. 20161107 22:58:09< vultraz> that is, did you test and not find it, or did not test? 20161107 22:58:28< celticminstrel> BTW, are you sure viewport is intended for the main game screen? It seems to be used by the regular listbox. 20161107 22:58:35< celticminstrel> But only if new_widgets is true. 20161107 22:58:46< celticminstrel> I did not test. 20161107 22:58:57< vultraz> I have no idea anymore 20161107 22:58:59< vultraz> ask mordante 20161107 23:01:20< celticminstrel> So many errors... 20161107 23:01:42< celticminstrel> Most of them are "must use class tag blah blah blah" because variables are hiding class names. 20161107 23:02:13< vultraz> celticminstrel: is this resolved? https://gna.org/bugs/?22991 20161107 23:02:25< vultraz> ie, are all mac builds 64 bit now? 20161107 23:03:25< celticminstrel> Think so. 20161107 23:03:46< celticminstrel> In fact I'm pretty sure 10.6 is no longer supported either.+ 20161107 23:04:03< celticminstrel> Though maybe it'll manage to run on 10.6 anyway. 20161107 23:05:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161107 23:06:10 * celticminstrel can only use the 32-bit kernel even though the processor is defintiely 64-bit; something to do with the firmware. 20161107 23:08:15< vultraz> can i close that then? 20161107 23:10:09< irker540> wesnoth: Charles Dang wesnoth:master 81659462eb33 / data/core/terrain-graphics.cfg: Made Chasm Bridges draw on the same layer as other bridges https://github.com/wesnoth/wesnoth/commit/81659462eb331801bdcf77cbb5008393ecf9846b 20161107 23:10:18-!- Appleman1234 [~Appleman1@KD106161207002.au-net.ne.jp] has quit [Ping timeout: 252 seconds] 20161107 23:10:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20161107 23:10:48< celticminstrel> Sure? 20161107 23:11:00< celticminstrel> I hope you tested the chasm bridges. 20161107 23:11:18< vultraz> yes 20161107 23:11:31< vultraz> it makes them be affected by the same bug as the other ones now 20161107 23:12:22< celticminstrel> Uhhh. Okay then? 20161107 23:12:35< celticminstrel> And that's supposed to be a good thing? 20161107 23:13:05< vultraz> now they'll have consistent behavior once the bug is fixed 20161107 23:13:06< vultraz> :) 20161107 23:14:17< celticminstrel> :| 20161107 23:14:21< celticminstrel> Well true but. 20161107 23:15:35< vultraz> :) :) :) 20161107 23:15:47< celticminstrel> ... 20161107 23:16:02< irker540> wesnoth: Gregory A Lundberg wesnoth:master 8e1172e80602 / src/tools/key_test.cpp: Delete ancient test of SDL keyboard handling. https://github.com/wesnoth/wesnoth/commit/8e1172e80602d057a3ac0dd114074d0e58266b76 20161107 23:16:04< irker540> wesnoth: Charles Dang wesnoth:master 1dbd7016abcd / src/tools/key_test.cpp: Merge pull request #867 from GregoryLundberg/GL_delete_old_test_code https://github.com/wesnoth/wesnoth/commit/1dbd7016abcd90ab3285aad1769002b8bcb36acf 20161107 23:16:10< irker540> wesnoth: Gregory A Lundberg wesnoth:master 4742988125bb / src/ (10 files in 4 dirs): Delete last vestiges of old networking code. https://github.com/wesnoth/wesnoth/commit/4742988125bb2fc4520aa82237725ce10b2a5ebd 20161107 23:16:12< irker540> wesnoth: Charles Dang wesnoth:master e8ee1803c219 / src/ (10 files in 4 dirs): Merge pull request #866 from GregoryLundberg/GL_delete_old_networking https://github.com/wesnoth/wesnoth/commit/e8ee1803c21970eaaad75178fb308398df5a8eec 20161107 23:17:11< tad_carlucci> One more coming deleting old Google NaCL support. Then I'll take a look at LOW_MEM. 20161107 23:17:36< tad_carlucci> The NaCL changes may take a bit. I found some stuff for it outside the src tree I want to check out. 20161107 23:18:33-!- Bonobo [~Bonobo@2001:44b8:254:3200:8d7a:9e76:8342:3bdc] has joined #wesnoth-dev 20161107 23:18:37< celticminstrel> LOW_MEM might be better left until after my rename. 20161107 23:18:55< celticminstrel> I'm not sure if it would conflict, but I think there's a small chance. 20161107 23:19:11-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection] 20161107 23:20:12< tad_carlucci> It's all in the one directory as near as I can tell. And some support scripts in /utils plus maybe some build toolsets and a few minor references. I'm looking now. If I get the PR up before you're done, I'll handle any merge conflicts. 20161107 23:21:34< celticminstrel> Okay. 20161107 23:25:44-!- Appleman1234 [~Appleman1@KD106161202234.au-net.ne.jp] has joined #wesnoth-dev 20161107 23:38:42< irker540> wesnoth: Charles Dang wesnoth:master 0a6a1ab80ed1 / data/core/ (terrain-graphics.cfg terrain-graphics/new-macros.cfg): Draw Dwarven Castle <-> Chasm transitons under bridges https://github.com/wesnoth/wesnoth/commit/0a6a1ab80ed180f3f316f6d02eb2a0874bd5e3df 20161107 23:38:52< vultraz> celticminstrel: annnnd fixed ^ 20161107 23:38:56< celticminstrel> ... 20161107 23:39:09< celticminstrel> Are you even thinking these changes through. 20161107 23:39:21< vultraz> indeed 20161107 23:39:23< vultraz> why? 20161107 23:41:31-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds] 20161107 23:41:49< vultraz> celticminstrel: no, really, is there something objectionable? 20161107 23:42:25< celticminstrel> Well, it seems like you changed the chasm bridges and then realized it broke something with castle-chasm. 20161107 23:42:33< vultraz> No 20161107 23:42:52< vultraz> Chasm bridges were drawn as overlays and not affected by the bug 20161107 23:42:57< celticminstrel> Hmm, okay. 20161107 23:42:59< vultraz> So I moved chasm bridges down 20161107 23:43:17< vultraz> then i fixed the bug where dc <-> chasm transitions were drawn OVER bridges 20161107 23:43:35< vultraz> which makes bridges draw 'over' the walls of dwarven castles but under the walls of all other 20161107 23:44:06< vultraz> (also, is it supposed to be intentional that wesnothd never quits if you host a networked game?) 20161107 23:44:30< celticminstrel> Doubt it. 20161107 23:44:53< irker540> wesnoth: Charles Dang wesnoth:master ced698e75f58 / projectfiles/CodeBlocks/wesnothd.cbp: Updated CB projfile https://github.com/wesnoth/wesnoth/commit/ced698e75f58a184da20c3163a5c0d2683ab1071 20161107 23:44:55< vultraz> i just tried to build wesnothd and couldn't 20161107 23:45:00< vultraz> wouldn't link 20161107 23:45:09< celticminstrel> Well fun. 20161107 23:45:21< vultraz> turns out there were 2 wesnothd processes running every since i tested stuff on sunday :| 20161107 23:45:35< vultraz> which was preventing linking 20161107 23:45:39< vultraz> that seems rather bad 20161107 23:45:59< shadowm> How did you launch them? 20161107 23:46:15< vultraz> via the in-game menu option 20161107 23:46:22-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind] 20161107 23:46:41< shadowm> That's supposed to make them quit after a few minutes of inactivity... 20161107 23:46:53< shadowm> (Inactivity being defined as no games being played.) 20161107 23:47:40< shadowm> s/games being played/people being on the server/ 20161107 23:48:13< tad_carlucci> They don't quit if you crash out or don't start a game. 20161107 23:48:16< celticminstrel> Now I'm getting an incomprehensible error... :| 20161107 23:48:16< shadowm> Perhaps on Windows it's not detecting player disconnections correctly? 20161107 23:48:31< celticminstrel> "error: use of undeclared identifier 'content_grid'" 20161107 23:48:37< celticminstrel> Pointing at the declaration of content_grid 20161107 23:48:41< tad_carlucci> There are times I need to killall wesnothd on linux, too 20161107 23:48:59< shadowm> Then it's probably a regression from the asio port. 20161107 23:49:20< vultraz> certainly seem so 20161107 23:49:22< celticminstrel> Oh. 20161107 23:49:35< vultraz> I don't know if it's potentially dangerous, but it's certainly unexpected. 20161107 23:49:40< shadowm> Yep, still running from me, definitely new. :/ 20161107 23:49:47< celticminstrel> I think I figured it out. 20161107 23:50:17< celticminstrel> Speaking of regressions from the asio port, rooms. 20161107 23:50:18< shadowm> It's not dangerous as long as wesnothd isn't vulnerable to anything, but it should be considered a blocker regardless. 20161107 23:50:40< vultraz> I'll file a bug 20161107 23:53:00< shadowm> 20161107 20:52:46 info server: Lan server has been empty for 82 seconds. Shutting down! 20161107 23:53:08< shadowm> This is what 1.12 did just now. 20161107 23:53:54< shadowm> (Note to past whoever: "LAN" is an acronym.) 20161107 23:54:50< shadowm> celticminstrel: What about rooms? 20161107 23:55:10< celticminstrel> Room manager wasn't ported. 20161107 23:55:21< vultraz> shadowm: we lost room support 20161107 23:55:31< shadowm> Yeah, I could never convince him to care about rooms because the GUI1 lobby didn't support them. 20161107 23:55:33< vultraz> I initially was fine with this until I needed room support :| 20161107 23:56:01< shadowm> ¯\_(ツ)_/¯ 20161107 23:56:13< shadowm> That's the kind of thing that happens when you don't plan far enough ahead. 20161107 23:56:18< tad_carlucci> Um .. are you talking about src/server/room_manager et al you just merged? 20161107 23:56:27< vultraz> I've asked him to reimplemnt them but he said it'd be a lot of work. 20161107 23:56:34< celticminstrel> tad_carlucci: Wait, did you delete it? 20161107 23:56:37< vultraz> tad_carlucci: that's the old code, unused. 20161107 23:56:42 * tad_carlucci nods 20161107 23:56:47< celticminstrel> I distinctly recall asking Jyrki not to in a previous PR. 20161107 23:57:07< celticminstrel> :| 20161107 23:57:20< shadowm> Communication~~~~ 20161107 23:57:54< celticminstrel> Sure it's the old code unused, but maybe it's a useful base to work off of. 20161107 23:58:06< vultraz> it's always in git history :P 20161107 23:58:19< celticminstrel> True. Still annoyed though. 20161107 23:58:52< celticminstrel> Maybe you should try to give other people more of a chance to review PRs before you go and merge them. 20161107 23:59:20 * celticminstrel probably would've said something if not for being swamped by the renaming.. --- Log closed Tue Nov 08 00:00:02 2016