--- Log opened Sat Jan 27 00:00:44 2018
20180127 00:52:04-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20180127 02:32:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180127 02:32:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180127 02:35:57-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20180127 02:36:54-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 246 seconds]
20180127 02:36:55-!- wedge010 is now known as wedge009
20180127 02:40:40-!- Coffee_irc [~david@220-244-89-194.tpgi.com.au] has joined #wesnoth-dev
20180127 03:06:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20180127 03:11:55-!- celticminstrel is now known as celmin|sleep
20180127 07:58:25-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20180127 08:00:12-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-dev
20180127 08:40:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20180127 09:01:03-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 256 seconds]
20180127 09:14:47-!- Bonobo [~Bonobo@220-244-89-194.tpgi.com.au] has joined #wesnoth-dev
20180127 09:21:06-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20180127 10:18:58-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20180127 10:22:33-!- Bonobo [~Bonobo@220-244-89-194.tpgi.com.au] has quit [Ping timeout: 264 seconds]
20180127 10:23:44-!- Bonobo [~Bonobo@220.244.89.194] has joined #wesnoth-dev
20180127 10:37:48-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20180127 10:48:09-!- Bonobo [~Bonobo@220.244.89.194] has quit [Ping timeout: 256 seconds]
20180127 10:49:25-!- Bonobo [~Bonobo@220-244-89-194.tpgi.com.au] has joined #wesnoth-dev
20180127 10:53:44-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20180127 11:06:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180127 11:17:24-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20180127 12:04:49-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20180127 12:16:25< Soliton> vultraz: i guess you're not considering bringing resources::screen back?
20180127 12:17:07< vultraz> No?
20180127 12:18:43< Soliton> another thing to update the surrender PR for. probably other PRs as well.
20180127 12:19:12< Soliton> just seems like a fairly useless change to me still.
20180127 12:20:49< Soliton> i'm probably going to commit the surrender stuff once i get it to run again. before it gets broken again by further refactors.
20180127 12:34:28< Soliton> btw, i still consider the change of resources::units to display::get_singleton()->get_units() as not useless but a bad idea.
20180127 12:37:31< vultraz> you did not mention this
20180127 12:38:50< vultraz> I only re-added resources::units for a specific case in the editor
20180127 12:38:56< vultraz> I realized I didn't need it
20180127 12:39:46< Soliton> you still haven't explained why going through the display singleton is better than resources:units.
20180127 12:40:29< vultraz> Because I wanted to remove resources::units
20180127 12:41:21< vultraz> I'm trying to gradually move things toward a design where the things that need to be accessed are readily available to the things that need them, instead of keeping random global pointers around just because one bit of code needs to reach halfway across the codebase and grab a piece of data it didn't have before.
20180127 12:41:51< Soliton> right, so again how is the display singleton better?
20180127 12:42:20< Soliton> how is that not "reaching halfway across the codebase"?
20180127 12:43:44< vultraz> it kinda is, but it's a broad accessor (having one display makes sense) instead of specialized, and it's managed by its own class.
20180127 12:44:54< Soliton> having one display makes sense, ok. so having resources::screen makes sense as well, no?
20180127 12:45:29< loonycyborg> hmm actually it doesn't, having multiple displays would allow support for multihead setups
20180127 12:45:37< Soliton> then if having resources::units makes no sense it doesn't make sense to have the same thing via display.
20180127 12:46:05< loonycyborg> like you could have gui spread over multiple screens
20180127 12:46:14< loonycyborg> some games actually have support for this..
20180127 12:46:19< Soliton> yes, singletons in generally are not great design.
20180127 12:46:32< vultraz> since game_display::singleton utilizes the singleton ptr in the base class, I felt it more consistent
20180127 12:46:43< Soliton> but that's probably a bigger change with our display...
20180127 12:47:40< loonycyborg> I wonder how wesnoth could benefit from multihead
20180127 12:47:43< Soliton> vultraz: imagine the resource namespace is just an alias so straight up replacing it with something else helps nothing and is probably just less readable.
20180127 12:48:13< Soliton> what would help is getting away from the singleton concept.
20180127 12:48:40< loonycyborg> how else can you get a display?
20180127 12:49:05< loonycyborg> with a global function?
20180127 12:49:22< vultraz> I think it makes it more readable, though. Those are variations of the display class singleton. It's not entirely clear that resources::screen was the game screen only. Many times I've mistaken it for the base display class or even the `CVideo` class
20180127 12:50:10< Soliton> well, perhaps it needs a better name than screen then?
20180127 12:50:41< Soliton> the thing is though that that change is pretty much just about naming.
20180127 12:50:57< vultraz> if it's so minor why do you care so much
20180127 12:50:58< vultraz> :|
20180127 12:51:39< loonycyborg> maybe because it caused a merge conflict :P
20180127 12:51:40< vultraz> It seems *any* time I make a change you're standing there in the background tsk-ing disapprovingly and shaking your head about Unproductive Work
20180127 12:52:38< Soliton> i don't really, as i said the resources:units part is much more important. that said maybe you should discuss renaming such an integral part of wesnoth with your fellow developers.
20180127 12:53:12< Soliton> especially since you probably want the name to be easily understood by them as well.
20180127 12:53:20< vultraz> jesus christ, man, it's a damn variable. Do we need to hold committee?
20180127 12:53:46< vultraz> it literally cannot get any clearer than it is now
20180127 12:54:13< Soliton> ok, great. so focus on the more important parts of the discussion then.
20180127 12:54:44< vultraz> you still haven't said why getting rid of resources::units is bad
20180127 12:58:39< vultraz> I replaced almost every single use of resources::units with an accessor via resources::gameboard awhile back. But that did not suffice for the unit ability code since it was executed in the context of the editor and the editor has no game_board and the ability code needs to check units. So I re-added resources::units as a quick fix. What I've done now is get the units from a more general context. game_board inherits from
20180127 12:58:39< vultraz> display_context, and the display class holds a pointer to the "current" display_context for lack of better word. So instead of setting resources::units in editor::map_context (which also inherits from display_context), I just accessed, via the display class, whatever unit_map was in the current display_context at the time. That means it grabs the game_board's in-game and the map_context's in-editor. 
20180127 13:00:54< vultraz> Soliton: does that answer your question
20180127 13:02:45< Soliton> i suppose that makes sense in the context of display. still pretty much global and weird to access unit_map via display.
20180127 13:03:36< vultraz> I agree
20180127 13:04:14< Soliton> if display somehow has an inherit relation to units then it'd be fine but this way it's just a worse "name" to access units IMO.
20180127 13:04:47< Soliton> nevertheless i understand better why you did it.
20180127 13:04:59< vultraz> Would be nice to find a better solution. Perhaps even just to add an accessor for the display context and let the caller do what it needs with it, instead of individual getters in the display class
20180127 13:05:21< vultraz> Sadly, the display class is a mess
20180127 13:06:26< Soliton> IMO first step would be to decouple display from map and unit stuff. after getting rid of such dependencies one can think about improving the display singleton if it makes sense.
20180127 13:08:56< vultraz> That’s rather the point of display_context
20180127 13:09:38< Soliton> doesn't sound too decoupled but i haven't looked in detail on how display_context is handled/used.
20180127 13:12:36< vultraz> There’s so much work to be done
20180127 13:13:01< vultraz> Which is why I get so frustrated when you seem to be against any small, incremental change.
20180127 13:13:24< Soliton> i'm against changes where i don't see the increment. :-P
20180127 13:15:29< Soliton> i'm not sure f.e. how much fun it'll be to update your accelerated rendering PR with all the refactors. unless you're doing that continuously.
20180127 13:15:52< Soliton> and you're very familiar with the changes so it's easiest for you.
20180127 13:16:07< Soliton> still those are things to consider IMO.
20180127 13:16:24< Soliton> i'm not saying any rename is a bad idea.
20180127 13:17:35< vultraz>  I haven't updated a_r in months
20180127 13:17:55< vultraz> I expect many, many, many hours of painful conflict resolution
20180127 13:18:28< vultraz> I keep thinking I should do it, but...
20180127 13:18:37< vultraz> I figured I'll wait until I merge it after we branch for 1.15
20180127 13:20:51< vultraz> I tried pulling as many changes from it to master as I could
20180127 13:34:29-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20180127 14:13:11< Soliton> "Something is wrong with the add-on version check database supporting the multiplayer lobby. Please report this at http://bugs.wesnoth.org."
20180127 14:13:19< Soliton> what is that telling me?
20180127 14:14:13< vultraz> Oh dear..
20180127 14:14:21< vultraz> I can’t remember what that means exactly though..
20180127 14:14:27< vultraz> Just grep the message
20180127 14:14:52< Soliton> can't join a mp game with a standard map because of that it seems.
20180127 14:15:46< Soliton> wesnoth: src/gui/core/event/distributor.cpp:169: void gui2::event::mouse_motion::signal_handler_sdl_mouse_motion(gui2::event::ui_event, bool&, const point&): Assertion `mouse_focus_' failed.
20180127 14:15:52< Soliton> :-(
20180127 14:16:21< Soliton> other client closed the game and my client crashed.
20180127 14:16:56< vultraz> What the hell are you doing o.o
20180127 14:17:13< Soliton> trying to play an mp game, sorry.
20180127 14:21:03< vn971> Soliton: there was a notice recently that the server will be re-started. (I saw such message on 1.12 at least.)
20180127 14:21:53< Soliton> i wrote it. :-)
20180127 14:22:27< Soliton> wesnothd is probably still going to be up for a while though.
20180127 14:23:34< Soliton> looks like i can't quickly figure out how to get chat messages on stdout by trial and error.
20180127 14:25:35< Soliton> hmm, looks like it's not possible at all.
20180127 14:25:56< vultraz> Possibly?
20180127 14:34:13-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20180127 14:34:23< Soliton> wow, --log-debug=all is completely useless nowadays.
20180127 14:37:51-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds]
20180127 14:37:52-!- wedge010 is now known as wedge009
20180127 14:41:18< Soliton> vn971: i'm afraid my guess was wrong. no way to get wesnoth to output the chat messages.
20180127 14:41:40< Soliton> so save/replay is your only chance.
20180127 14:47:39< Soliton> https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/lobby.cpp#L946  that's where that error message comes from. seems like that should allow the player to continue instead of returning.
20180127 14:48:19< Soliton> now to figure out why that was triggered in the first place...
20180127 14:56:21-!- octalot [~steve@91.141.1.168.wireless.dyn.drei.com] has joined #wesnoth-dev
20180127 15:03:21-!- midzer_ [~quassel@p4FFAF1CA.dip0.t-ipconnect.de] has joined #wesnoth-dev
20180127 15:04:11-!- midzer [~quassel@p5B3120FC.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds]
20180127 15:09:19-!- midzer_ [~quassel@p4FFAF1CA.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds]
20180127 15:11:27-!- midzer [~quassel@p4FFAF1F1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20180127 15:27:36< vn971> Soliton: well I'm interested in saving lobby PM-s and pre-game chat messages, so I guess there's no easy solution for me, yet. Like the sad screen when you left wesnoth running -- "Ping timeout". And you can't scroll up and see if you had private messages. Only click OK and see all history is lost forever.
20180127 15:28:12< vn971> (To others: we started discussion on #wesnoth, I asked if there's a way to save chat history for a running wesnoth client.)
20180127 15:51:23-!- octalot [~steve@91.141.1.168.wireless.dyn.drei.com] has quit []
20180127 15:51:39-!- celmin|sleep is now known as celticminstrel
20180127 15:56:25< celticminstrel> Soliton: The thing about the resources namespace was that it was just a collection of pointers that needed to be updated at the appropriate points in the program. Going through the display singleton divests us of the need to make sure they're always updated when they should be. Adding back resources::units as a function rather than a pointer would also satisfy that though.
20180127 15:56:30< celticminstrel> Also vultraz ^
20180127 15:57:41< Soliton> because there seems to be a strong coupling between the display and units which seems bad.
20180127 15:58:11< celticminstrel> Yeah, that does seem a bit weird.
20180127 15:58:40< Soliton> if that coupling really is natural and makes sense it's all good.
20180127 16:03:43< Soliton> i'm pretty sure when the resources namespace was started there was no need to update any pointers there. so now that there is turning it into functions that hide those implementation details would be a good idea indeed.
20180127 16:19:00-!- DeFender1031 [~DeFender1@89-138-239-68.bb.netvision.net.il] has joined #wesnoth-dev
20180127 16:27:52< celticminstrel> vultraz: Basically that would just mean adding a function resources::units() {return display::get_singleton()->get_units();} so it wouldn't be too bad, right? And it's shorter too.
20180127 16:38:59-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20180127 16:50:05-!- midzer_ [~quassel@p5B312EB9.dip0.t-ipconnect.de] has joined #wesnoth-dev
20180127 16:50:35-!- midzer [~quassel@p4FFAF1F1.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20180127 16:50:51-!- midzer_ is now known as midzer
20180127 17:07:45-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180127 17:07:51-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180127 17:33:29-!- Soliton_ [~soliton@wesnoth/developer/soliton] has joined #wesnoth-dev
20180127 17:39:10-!- Soliton [~Soliton@wesnoth/developer/soliton] has quit [Quit: Battle for Wesnoth: http://www.wesnoth.org/]
20180127 17:39:45-!- Soliton_ is now known as Soliton
20180127 17:40:18-!- shadowm_vps [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20180127 17:52:22-!- irker676 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20180127 17:52:22< irker676> shikadilord: Ignacio R. Morelle valen:master 0d97e19518d7 / bin/valen.pl: valen: 1.12 is now front-facing on basilic https://github.com/shikadilord/valen/commit/0d97e19518d76043fea245f3b9f7992ce61cf4d2
20180127 17:55:44-!- Bonobo [~Bonobo@220-244-89-194.tpgi.com.au] has quit [Ping timeout: 256 seconds]
20180127 18:13:30< vn971> I wonder.. There's some kind of backup ongoing, right?
20180127 18:13:46< irker676> shikadilord: Ignacio R. Morelle valen:master a9a0498fb3aa / index.php: web: Update support info to include Discord and Twitter https://github.com/shikadilord/valen/commit/a9a0498fb3aa270b6b7fa6f7b66623f33630a6f8
20180127 18:14:21< vn971> what I wonder is if it can/should be done with 1 CPU core instead of all of them (if indeed CPU is the bottleneck).
20180127 18:14:55< shadowm_vps> Backups are being done, but they are also done daily and weekly. What is being done involves far more than just backups.
20180127 18:17:06< vn971> ok-ok, I don't doubt you understand the process very well.
20180127 18:17:16< Soliton> most of wesnoth.org is alreadyy down and it's still going to be awhile until everything is up again.
20180127 18:18:09< vn971> Just heard some talk about backup, and thought if reducing parallelism for backups would have any positive impact on MP server "playability". Probably an irrelevant consideration tho.
20180127 18:18:59< Ravana_> more people are on server2 already anyways
20180127 18:29:09< shadowm_vps> Backups are done one at a time I'm pretty sure.
--- Log opened Sat Jan 27 21:14:10 2018
20180127 21:14:20-!- lobby [~wesnoth@wesnoth/bot/lobby] has joined #wesnoth-dev
20180127 21:14:20-!- Topic for #wesnoth-dev: 1.13.11 (1.14 Beta  3) scheduled for Sunday, February 4th 00:01 UTC | Wesnoth Developers Channel | >>> Want to help? Go here: https://r.wesnoth.org/t42911 (and thanks!) <<< | Discord Server: https://discord.gg/battleforwesnoth | Logs: http://irclogs.wesnoth.org | Bug tracker: https://bugs.wesnoth.org
20180127 21:14:20-!- Topic set by vultraz [uid24821@wesnoth/developer/vultraz] [Tue Jan 23 23:44:00 2018]
20180127 21:14:20[Users #wesnoth-dev]
20180127 21:14:20[ aeth           ] [ elias       ] [ matthiaskrgr] [ Soliton    ] 
20180127 21:14:20[ AI0867         ] [ EliDupree   ] [ midzer      ] [ stikonas   ] 
20180127 21:14:20[ aidanhs        ] [ esr         ] [ minzbonbon  ] [ syrma[m]   ] 
20180127 21:14:20[ APic           ] [ fabi        ] [ new_one     ] [ TadCarlucci] 
20180127 21:14:20[ Appleman1234   ] [ Gambit      ] [ nore        ] [ TC01       ] 
20180127 21:14:20[ atarocch       ] [ heirecka    ] [ nurupo      ] [ TheJJ      ] 
20180127 21:14:20[ boucman        ] [ higgins     ] [ octalot     ] [ timotei_   ] 
20180127 21:14:20[ celticminstrel ] [ Ivanovic    ] [ Oebele      ] [ tomreyn    ] 
20180127 21:14:20[ ChipmunkV[m]   ] [ iwaim___    ] [ oldlaptop   ] [ vincent_c  ] 
20180127 21:14:20[ Coffee_irc     ] [ janebot     ] [ Polsaker    ] [ vn971      ] 
20180127 21:14:20[ commavir       ] [ Jetrel_bot  ] [ pydsigner   ] [ wedge009   ] 
20180127 21:14:20[ crimson_penguin] [ lobby       ] [ Ravana_     ] [ Yaiyan     ] 
20180127 21:14:20[ DDR            ] [ loonycyborg_] [ Rhonda      ] [ zacklocx[m]] 
20180127 21:14:20[ DeFender1031   ] [ madmax28    ] [ shadowm_vps ] [ zookeeper  ] 
20180127 21:14:20-!- Irssi: #wesnoth-dev: Total of 56 nicks [0 ops, 0 halfops, 0 voices, 56 normal]
20180127 21:14:49-!- Channel #wesnoth-dev created Tue Jan 27 05:28:41 2009
20180127 21:15:09-!- Soliton [~soliton@wesnoth/developer/soliton] has quit [Disconnected by services]
20180127 21:15:14-!- Soliton_ [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev
20180127 21:15:31-!- Soliton [~soliton@wesnoth/developer/soliton] has joined #wesnoth-dev
20180127 21:15:36-!- Irssi: Join to #wesnoth-dev was synced in 85 secs
20180127 21:15:47-!- Soliton [~soliton@wesnoth/developer/soliton] has quit [Client Quit]
20180127 21:15:50-!- Soliton_ is now known as Soliton
20180127 21:16:01-!- Soliton_ [~soliton@wesnoth/developer/soliton] has joined #wesnoth-dev