--- Log opened Tue Feb 05 00:00:38 2019 20190205 00:36:21<+wesdiscordbot> How much ram? 20190205 01:01:21< irker845> wesnoth/wesnoth:master nemaara 80f47afc44 DiD S1: fixed indentation issues AppVeyor: vs2015/Release Failed 20190205 01:01:22< irker845> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/22120907 20190205 01:15:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190205 02:05:15< irker845> wesnoth/wesnoth:master nemaara 51e7915fd2 DiD S5: dialogue revision AppVeyor: All builds passed 20190205 03:32:48< irker845> wesnoth/wesnoth:master nemaara 2f5b47b0e4 DiD S6: fixed bad indents AppVeyor: 1/4 builds failed 20190205 03:32:49< irker845> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22120135 20190205 05:05:31-!- celmin|away is now known as celmin|sleep 20190205 06:01:21< irker845> wesnoth/wesnoth:master nemaara 80f47afc44 DiD S1: fixed indentation issues AppVeyor: 1/4 builds failed 20190205 06:01:22< irker845> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/22120907 20190205 06:16:22-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190205 07:09:56-!- valdar [~atarocch@93.56.172.28] has quit [Ping timeout: 272 seconds] 20190205 09:01:45-!- irker845 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190205 09:01:59-!- valdar [atarocch@nat/redhat/x-ilnxgzmkyapjkzin] has joined #wesnoth-dev 20190205 09:14:11< Soliton> i'm guessing the spirit_po stuff is doing lots of template stuff that blows up. 20190205 09:14:42< Soliton> 2.5 GB was not enough. 20190205 09:14:56<+wesdiscordbot> Can't it just use swap? 20190205 09:21:52< Soliton> that is 1.5 GB swap already. we just have 1 GB ram on server3. 20190205 09:26:14<+wesdiscordbot> isn't server3 a lot cause 20190205 09:26:43< Soliton> nope, that's server2. 20190205 09:26:55<+wesdiscordbot> :thonk: 20190205 09:27:03<+wesdiscordbot> then I'm misremembering 20190205 09:27:17<+wesdiscordbot> or perhaps you said server3 might be resurrected 20190205 09:27:19< Soliton> server3 is now uptodate debian stable. 20190205 09:28:07< Soliton> well, server2 could in theory as well but it has a very old os so likely lots of hoops to jump through to build current wesnothd. 20190205 09:32:22< Soliton> if there's be a simple way to reorganize some sources to remove translation stuff from wesnothd as a dependency that would be helpful. i don't think it'll ever make sense to support translations in the server or at least not in the same way as everywhere else. 20190205 09:32:51<+wesdiscordbot> wesnothd doesn't even send translations over the network 20190205 09:32:56<+wesdiscordbot> it's broken 20190205 09:33:39< Soliton> where do you expect it to send translations? 20190205 09:34:07<+wesdiscordbot> good question 20190205 09:34:19<+wesdiscordbot> I think I misphrased that 20190205 09:34:44< loonycyborg> server still has own messages it emits to stdout 20190205 09:35:05< loonycyborg> messages it sends to clients are their responibility to translate 20190205 09:35:16<+wesdiscordbot> what is the thing that is broken.... 20190205 09:35:20<+wesdiscordbot> something about t_strings 20190205 09:35:52< loonycyborg> you mean it should send translated messages? 20190205 09:36:03< loonycyborg> then client will have to send it the expected locale 20190205 09:36:34< loonycyborg> anyway I think it's possible to factor out spirit_po use from filesystem_boost to other sourcefile 20190205 09:36:42< loonycyborg> that would be only used in libwesnoth 20190205 09:38:00<+wesdiscordbot> filesystem_boost doesn't include spirit_po 20190205 09:38:11< loonycyborg> derp 20190205 09:38:13< loonycyborg> I confused 20190205 09:38:20< loonycyborg> I mean gettext_boost.cpp 20190205 09:38:31< loonycyborg> and it exists at that name only in 1.14 20190205 09:38:40< loonycyborg> probably this got refactored in master 20190205 09:39:53<+wesdiscordbot> yes 20190205 09:39:54<+wesdiscordbot> well 20190205 09:39:56<+wesdiscordbot> renamed 20190205 09:40:24<+wesdiscordbot> this specific problem didn't get fixed 20190205 09:52:41< loonycyborg> seems it might be hard to untangle it. spirit_po is indirectly used in translation_manager singleton which is used in all gettext wrappers in gettext_boost.cpp 20190205 09:53:19< loonycyborg> and some core functions use those wrappers 20190205 09:53:55< Soliton> which core functions? 20190205 09:54:13< loonycyborg> game_config::get_default_title_string for example 20190205 09:54:20<+wesdiscordbot> I still don't understand the logic of declaring a static object on the heap to which you then grab a pointer rather than just global static in a namespace. 20190205 09:55:00< loonycyborg> global statics can introduce contruction order issues 20190205 09:55:15< loonycyborg> static objects are contructed in undefined order 20190205 09:55:21<+wesdiscordbot> ah right 20190205 09:55:31< loonycyborg> if there are interdependencies on them it's undefined behavior 20190205 09:55:40<+wesdiscordbot> yes, I've run into that 20190205 09:55:41< Soliton> and that is in libwesnoth_core? doesn't seem like the server would use that. 20190205 09:56:07< loonycyborg> everything is using libwesnoth_core 20190205 09:56:19<+wesdiscordbot> still, unless I've forgotten, you can just declare the object static in the function body sans `new. 20190205 09:56:21< Soliton> yes, that is why i asked if it's in there. 20190205 09:56:42<+wesdiscordbot> it's the use of new that puzzles me 20190205 09:56:42<+wesdiscordbot> loonycyborg: Unspecified, not undefined. The compiler is still required to initialize them in some order. It can't just do whatever it likes. 20190205 09:57:10< loonycyborg> it's undefined only in case of interdependency 20190205 10:00:13< loonycyborg> Soliton: I think it's because some utility functions that are used pretty much everywhere translate their strings 20190205 10:01:32< Soliton> it'd be great to figure out which functions those are to decide whether it's easy or not to reorganize stuff so the server does not use them if it really does. 20190205 10:02:07< loonycyborg> lol if I remove libwesnoth_core from wesnothd it still builds 20190205 10:02:39<+wesdiscordbot> The names of these libraries are quite confusing. 20190205 10:03:13<+wesdiscordbot> I don't recall what libwesnoth_core is, but it might be indeed "the code shared between Wesnoth client and Boost unit tests", i.e. not used by wesnothd. 20190205 10:03:51< loonycyborg> https://gist.github.com/loonycyborg/c1a124a8f011e2a047ca76e405d7c809 20190205 10:04:02< loonycyborg> Soliton: try that patch on that server 20190205 10:05:10< Soliton> thanks, i'll try after the current compile is done/fails. 20190205 11:36:03-!- irker124 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190205 11:36:03< irker124> wesnoth/wesnoth:master nemaara 981aa2aaa0 DiD S11: gameplay updates AppVeyor: All builds passed 20190205 12:51:35< Soliton> finally 3 GB was enough to compile it. 20190205 12:56:44< Soliton> loonycyborg: when i patch the else case for non-windows i get lots of undefined references to logging functions. 20190205 12:56:57< Soliton> something must have gone wrong in your test. 20190205 12:57:21< Soliton> perhaps you did not test on windows like your diff suggests. 20190205 13:16:35< Soliton> http://ix.io/1Ae9 those are all the symbols wesnothd needs from libwesnoth_core. if none of those depend on translations it should be possible to reorganize stuff so wesnothd can be built without compiling gettext. 20190205 13:38:53-!- celmin|sleep is now known as celmin|away 20190205 13:46:44< galegosimpatico> Please ping or DM me if you are going to be in Madrid ES in early March. 20190205 14:09:47< loonycyborg> ah yes too much distraction, changed it in wrong place 20190205 14:11:20< irker124> wesnoth/wesnoth:master nemaara 73f4a848c1 DiD S12: added code for flanking hero AppVeyor: All builds passed 20190205 15:25:50-!- Ravana [~Ravana@wesnoth/mp-mod/ravana] has quit [Ping timeout: 272 seconds] 20190205 15:50:47<+wesdiscordbot> @Vultraz Would it kill people if we brought the "Alternate Wesnoth Server" string back now that server3 is working again? 20190205 15:51:04<+wesdiscordbot> (this is why i hate hasty PR merges) 20190205 15:51:34<+wesdiscordbot> No it wouldn’t 20190205 16:00:13-!- valdar [atarocch@nat/redhat/x-ilnxgzmkyapjkzin] has quit [Ping timeout: 246 seconds] 20190205 16:40:09< irker124> wesnoth/wesnoth:master nemaara 1e22f1644d SotA S22: updated epilogue text AppVeyor: vs2015/Release Failed 20190205 16:40:10< irker124> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/22141233 20190205 16:55:46-!- Ravana [~Ravana@wesnoth/mp-mod/ravana] has joined #wesnoth-dev 20190205 17:40:30< irker124> wesnoth/wesnoth:master nemaara ad8e6d5303 SotA S22: updated epilogue text AppVeyor: vs2017/Release Failed 20190205 17:40:31< irker124> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22141234 20190205 17:47:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190205 17:57:25-!- gfgtdf [~Daniel@x4d011f54.dyn.telefonica.de] has joined #wesnoth-dev 20190205 18:02:08< gfgtdf> @Vultraz the reason why those static variables live on the heap is that not only the initilisation order can cause probem but also their destruction order (some global variables dtor might reference another global variable), by using new we basicially prevent those object ot be destructed at all. 20190205 18:04:07< gfgtdf> this is not a problem for simple classes since the os will cleanup those things (in partiuclar allocated ram, but i think also filehandles) anyways. 20190205 18:04:21< gfgtdf> when the programm ends. 20190205 18:04:51<+wesdiscordbot> Yeah, the OS cleans up everything it can. 20190205 18:06:25<+wesdiscordbot> The only things it can't help with is if you have something like some kind of network protocol that requires a custom termination message. The OS can't read your mind. 20190205 18:07:01<+wesdiscordbot> IPC resources are not automatically cleaned up in all cases as far as I remember 20190205 18:07:06< gfgtdf> there was a known wesnoth bug in the past where fonts would not be cleaned up properly when the programm ended. (meaing the files would stay locked) 20190205 18:07:39< loonycyborg> actually I don't see anything wrong with returning local static variable from get_some_singleton() 20190205 18:08:14< loonycyborg> it doesn't have to be a global really 20190205 18:08:34< gfgtdf> loonycyborg: even local static cariavles will be destrucede when the programm ends 20190205 18:08:37< gfgtdf> variables* 20190205 18:08:57<+wesdiscordbot> Also I don't think POSIX in particular guarantees that any resources are released at all 20190205 18:09:17<+wesdiscordbot> As in happens in practice but it is not a compliance requirement 20190205 18:11:18<+wesdiscordbot> I swear there's at least one kind of resource that Linux does not release upon process termination that can cause problems if you get into the habit of sending signal 9 recklessly 20190205 18:13:07<+wesdiscordbot> Also if you're dealing with certain graphics drivers (COUGH NVIDIA COUGH) I can 100% assure you that abnormal process termination can cause very interesting issues such as complete but temporary stalls on all GL calls 20190205 18:16:49<+wesdiscordbot> On the subject of i18n code in wesnothd, one issue is that wesnothd uses the config class for server config WML if I recall xorrectly 20190205 18:17:39<+wesdiscordbot> WML attributes may be t_strings and those in turn can be extracted as translated strings which requires calling the i18n code 20190205 18:18:33<+wesdiscordbot> So the server needs it unless it were to use a different version of config without t_string attributes 20190205 18:18:53<+wesdiscordbot> I have experienced OpenGL program crashing causing full-blown system freezes on AMD. (Although it was about six years ago, so it may be better now.) 20190205 18:19:34<+wesdiscordbot> Or alternatively t_string altered so it can use a dummy i18n backend that always returns strings as they are 20190205 18:23:07<+wesdiscordbot> It could be achieved by replacing the implementation of the gettext.hpp stuff at link time to be fair 20190205 18:36:03-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20190205 19:01:11-!- LovCAPONE [~LovCAPONE@198.168.27.218] has joined #wesnoth-dev 20190205 20:10:23-!- valdar [~atarocch@93.56.172.28] has joined #wesnoth-dev 20190205 20:34:36-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Quit: Caught sigterm, terminating...] 20190205 20:36:07-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20190205 20:40:41-!- irker124 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190205 20:56:38<+wesdiscordbot> Did someone report yet the odd behavior of the Chat line in the Game Lobby? It get's deselected whenever someone changes their leader. And at the same time it scrolls back to the start of the chat. 20190205 21:06:09-!- LovCAPONE [~LovCAPONE@198.168.27.218] has quit [Quit: Life is like a void pointer: you never know what you're going to get...] 20190205 21:26:49<+wesdiscordbot> Is it intended that the unit names are written in the alphabet of the person who loaded the MP save? 20190205 21:37:16< zookeeper> intended or not, i'd imagine that's pretty much unavoidable. 20190205 21:40:16-!- irker062 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190205 21:40:16< irker062> wesnoth/wesnoth:master nemaara 1e22f1644d SotA S22: updated epilogue text AppVeyor: 1/2 builds failed 20190205 21:40:16< irker062> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/22141233 20190205 21:41:16< zookeeper> since parts of the name generation system itself are translatable (instead of just a long list of hardcoded names), one can't take a name generated by a localized version of the name generator and re-translate it to another language anymore. 20190205 21:44:05< zookeeper> so if you have language X selected and recruit a unit, that's the name it'll forever be stuck with, since it's actually a non-translatable string created from translatable strings by the name generator. 20190205 21:44:23< zookeeper> (correct if i'm wrong) 20190205 21:49:32<+wesdiscordbot> The fun part is that it's only my units. The units of other side still have names using my alphabet. 20190205 21:56:22< zookeeper> oh? i don't know why that is, although i get the feeling it feels obvious as soon as someone explains the reason. 20190205 22:40:30< irker062> wesnoth/wesnoth:master nemaara ad8e6d5303 SotA S22: updated epilogue text AppVeyor: 1/2 builds failed 20190205 22:40:31< irker062> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22141234 20190205 22:41:34<+wesdiscordbot> My best guess: There is not just one name generated, but instead as many as there are different alphabets between the different players. So, for units not on my side my pc asks 'whats the name we decided for this unit in my alphabet'. But for my own unit it just reads the name that's written in the save file. 20190205 22:41:57<+wesdiscordbot> That's more of a 'What might be happening' instead of a 'why does it happen' though. :/ 20190205 22:51:33<+wesdiscordbot> Let me simplify this 20190205 22:52:24<+wesdiscordbot> In all cases the game generates names from the list of names for the current language. The resulting mashup of characters is not translatable, and that's what's sent to the server, and that's what the server sends to clients 20190205 22:53:37<+wesdiscordbot> Some translation teams (e.g. Japanese) leave the list of names for the generator intact instead of transliterating it to a different script than Latin so this is hardly ever a thing that players will notice 20190205 23:09:26-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds] 20190205 23:35:37-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] --- Log closed Wed Feb 06 00:00:39 2019