Times are UTC Toggle Colours
07:35:28 *** Supercheese has quit IRC 08:37:03 *** tycoondemon has quit IRC 08:37:18 *** tycoondemon has joined #openttd.dev 08:45:05 *** tycoondemon has quit IRC 08:50:22 *** ntoskrnl has joined #openttd.dev 09:42:07 *** tycoondemon has joined #openttd.dev 11:41:34 *** Ristovski has joined #openttd.dev 13:05:29 *** tycoondemon has quit IRC 13:07:00 <Belugas> hello 13:28:52 *** tycoondemon has joined #openttd.dev 14:46:58 *** SmatZ has quit IRC 14:48:03 *** SmatZ has joined #openttd.dev 14:48:06 *** ChanServ sets mode: +v SmatZ 16:45:31 *** Alberth has joined #openttd.dev 16:45:32 *** ChanServ sets mode: +v Alberth 17:02:01 <Rubidium> http://rbijker.net/openttd/fs5320.diff <- though they'll only know that when they get debug output as we won't show such a deep stacktrace in OpenTTD's UI 17:03:49 <planetmaker> well. He might not find that - nor get the stacktrace when they get bug reports from users 17:05:05 <Rubidium> although 50 times the same call in the stack trace might give a clue about it ;) 17:05:26 <planetmaker> :-) 17:06:11 <planetmaker> fair enough. So go for it :-) 17:06:40 *** frosch123 has joined #openttd.dev 17:06:40 *** ChanServ sets mode: +v frosch123 17:22:59 <frosch123> Alberth: did you read yesterday's log? 17:23:17 <Alberth> no, should I ? 17:23:22 <frosch123> we need a discussion about eints and devzone's future :) 17:23:35 <Alberth> k 17:23:37 <frosch123> personally i have settled meanwhile on an opinion, but you might know better 17:24:11 <frosch123> Alberth: problem is, that devzone and openttd.org are using mysql. but mysql is effectively dead (if not now, then 2015) 17:24:35 <frosch123> there is no python3 support with the library eints currently uses for mysql 17:24:53 <frosch123> so there are two options: someone find a different mysql library for python 3 17:25:02 <frosch123> or migrate devzone to postgresql 17:25:19 * Alberth votes for migration any day 17:25:46 <frosch123> yeah, i also think the only long term solution would be to use postgresql 17:25:50 <frosch123> and drop mysql 17:26:06 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25585 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 17:26:16 <planetmaker> right, so devzone should migrate from mysql to postgresql? 17:26:39 <frosch123> postgresql is the default in debian stable. it does not even ask :) 17:26:41 <planetmaker> maybe... we should talk in #openttdcoop.devzone then :-P 17:26:59 <Alberth> planetmaker: the other option is to fork mysql, and maintain it :p 17:26:59 <frosch123> that's why i used postgresql initially without asking anyone... because debian did not ask me either :) 17:27:17 <frosch123> Alberth: there are some forks of both mysql and the python interface to it :) 17:27:24 <Alberth> lots of people might be happy with that 17:27:24 <planetmaker> lol, Alberth :-) if so, there's already mariaDB as fork 17:27:29 <frosch123> but that does not feel right either :p 17:27:48 <Alberth> nah, postgresql is much better, I have heard 17:28:09 <frosch123> well, it also looked nicer from what i used so far :p 17:28:25 <planetmaker> ok... so... it "just" needs migrating 17:29:13 <planetmaker> the actual mysql database seems to be on a separate VM on the coop server 17:29:18 <Rubidium> yeah ;) 17:29:20 <planetmaker> so that might even be easy 17:29:48 <Alberth> such claims are dangerous until done :p 17:29:49 <planetmaker> one can create a drop-in replacement in postgresql and then swap 17:29:54 <planetmaker> yes, very :D 17:40:10 <Alberth> frosch123: where does 2015 come from? 17:40:31 * Alberth is thinking about NML & Python 3 17:40:49 <planetmaker> probably next debian release 17:41:00 <frosch123> http://en.wikipedia.org/wiki/Mysql#Legal_and_acquisition_impacts <- ctl+f on 2015 17:41:36 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25586 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 17:43:11 *** Supercheese has joined #openttd.dev 17:43:45 <planetmaker> interesting 17:47:47 <Alberth> lol, there is a 3to2 python convertor :p 17:48:05 <planetmaker> hehe 17:48:23 <planetmaker> Alberth, the biggest problem in moving from python2 to python3 for NML is the use of PIL 17:48:49 <planetmaker> if a replacement for that (pillow?) is found which does the jobs required, it certainly can be done 17:51:20 <Alberth> http://stackoverflow.com/questions/4836375/end-of-support-for-python-2-7 says at least until 2016 there'll be python2.7 support 18:03:40 <Rubidium> ouch... that diff -x -b of 1.3.1 vs 1.3 is bigger (in bytes) than 1.3 vs trunk 18:04:16 <Rubidium> s/that/the/ 18:04:20 <planetmaker> :-) 18:04:53 <Rubidium> only by 5199 bytes though 18:05:04 <Rubidium> ... but I can increase that difference by backporting some stuff 18:09:53 <Alberth> lol 18:45:40 *** Supercheese has quit IRC 19:21:52 *** Supercheese has joined #openttd.dev 19:32:07 <planetmaker> right... seems to cause no issue at least with xaroth's test client even when it does not understand the packet: http://devs.openttd.org/~planetmaker/patches/index.php?source=admin_rcon_end.diff (sending an rcon end packet to indicate rcon output from the previous rcon output line(s) are finished) 19:38:12 *** ntoskrnl has quit IRC 19:53:56 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25587 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:22:53 <planetmaker> http://devs.openttd.org/~planetmaker/patches/admin_pingpong.diff and the ping pong packets patch. To allow the admin script to get an idea of its latency 20:27:55 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25588 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:42:44 <Alberth> nice new DoS options! 20:43:14 <Alberth> more seriously, don't you run the admin at the local machine? 20:44:08 <planetmaker> Alberth, admin needs authentication 20:44:23 <planetmaker> without authentication ... no ping and pong 20:45:03 <Alberth> k, sounds good enough :) 20:45:14 <planetmaker> Alberth, and admin port allows to run it remote. Like myself running a logging client here to check on our server or so 20:45:32 <planetmaker> would be useful if it made loud noises for real problems :D 20:46:20 <planetmaker> and it keeps one of our admin port lib writers happy :D 20:46:42 <Alberth> sounds like a good plan as well :) 20:47:40 <frosch123> http://www.youtube.com/watch?v=JKv08vkBmpc <- planetmaker: you have such a thing in your bedroom connected to the devzone? 20:48:06 <planetmaker> hahaha :D 20:48:18 <planetmaker> scary idea 20:56:23 *** Alberth has left #openttd.dev 21:00:16 <Rubidium> I hope you're aware that not all console commands return immediately 21:00:33 <Rubidium> most notable are the content commands 21:01:17 <Rubidium> e.g. download shows a line for every downloaded file... but that's just in between somewhere 21:01:43 <Rubidium> and it also dumps a line when it, asynchronously, opened (or failed to open) a connection 21:02:01 <Rubidium> as well as the disconnect after a timeout 21:03:03 <planetmaker> meaning it might mis-represent an end as it interferes with another? 21:03:51 <Rubidium> it will send the end before actually ending "all" output of a command 21:04:19 <Rubidium> though, since content is highly asynchronous, you can do all kinds of commands in between in the user interface as well 21:04:30 <Rubidium> it's just something that should be noted somewhere 21:04:36 <planetmaker> indeed 21:05:06 <Rubidium> only 'problem' could be that content 'output' gets into the perceived output of other commands 21:05:21 <planetmaker> where'll be the place to note that, though? 21:05:26 <planetmaker> in some doxygen there? 21:06:36 <Rubidium> e.g. if you start a content download, then ask for the settings and between sending the request and receiving the result of list_settings you might receive the 'download complete' message 21:06:47 <Rubidium> which you'd probably assign to the list_settings stuff 21:07:28 <planetmaker> yeah. or to the content 21:07:36 <planetmaker> however you programme your admin port bot 21:08:12 <Rubidium> in any case... the rcon_end packet is sent in the same tick as the command is executed 21:08:52 <Rubidium> planetmaker: docs/admin_network.txt might be the best place with a note in the doxygen stuff 21:09:06 <planetmaker> ah, yes. good place. 21:09:37 <frosch123> hmm, i cam still reproduce fs#5635, but the content server does not log anything anymore 21:09:58 <frosch123> last time i tried i thought it would print the "send failed with error 32" thingie 21:10:01 <frosch123> but now it doesn't 21:10:56 <planetmaker> I keep that in mind for tomorrow, Rubidium. Thanks for that advice 21:11:03 <planetmaker> Bed now :-) Have a good night :-) 21:11:05 <Rubidium> might it just send an empty list for some reason? 21:11:27 <Rubidium> although that sounds somewhat stupid 21:11:42 <frosch123> hmm, oh, this looks suspicious 21:11:47 <frosch123> the connection does not time out 21:11:57 <frosch123> the client should have closed the connection by now 21:12:11 <frosch123> maybe it's a client problem then 21:12:25 <frosch123> last time i saw it sendnig out the request, but never receiving a result 21:12:45 <frosch123> but it should still close the connection when idle, shouldn't it? 21:13:08 <Rubidium> what is 'last time'? 21:13:17 <Rubidium> before or after I fixed the master server? 21:13:21 <frosch123> last week before you fixed the assertion 21:14:20 <Rubidium> or is the logic in the masterserver somehow broken? 21:14:38 <Rubidium> uhm... contentserver 21:16:25 <frosch123> hmm, now it loggedan error 32 21:16:31 <frosch123> no idea whether that was me waiting 21:17:09 <frosch123> ah, well i guess i have to try agani tomorrow what the client sends and receives exactly 21:17:17 <frosch123> maybe use tcpdump or so :p 21:17:25 <frosch123> night 21:17:33 *** frosch123 has quit IRC 23:09:23 *** Ristovski has quit IRC