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