Log for on 11th July 2013:
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
08:45:05  *** tycoondemon has quit IRC
08:50:22  *** ntoskrnl has joined
09:42:07  *** tycoondemon has joined
11:41:34  *** Ristovski has joined
13:05:29  *** tycoondemon has quit IRC
13:07:00  <Belugas> hello
13:28:52  *** tycoondemon has joined
14:46:58  *** SmatZ has quit IRC
14:48:03  *** SmatZ has joined
14:48:06  *** ChanServ sets mode: +v SmatZ
16:45:31  *** Alberth has joined
16:45:32  *** ChanServ sets mode: +v Alberth
17:02:01  <Rubidium> <- 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
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 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: || 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> <- ctl+f on 2015
17:41:36  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25586 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
17:43:11  *** Supercheese has joined
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>   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
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: (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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
20:22:53  <planetmaker> 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: || 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> <- 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
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

Powered by YARRSTE version: svn-trunk