| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| CIA-10 | mithro tpserver-cpp * r1560bf6821b7 /modules/games/minisec/ (minisec.cpp minisec.h): | 00:02 |
|---|---|---|
| CIA-10 | Added a better way for name generation. | 00:02 |
| CIA-10 | Added support so that the generator continues even if it runs out of predefined names. | 00:02 |
| CIA-10 | Added support for reading system names from a file. | 00:02 |
| CIA-10 | mithro tpserver-cpp * r0d6f214bac8d / (5 files in 2 dirs): Merge with git://git.thousandparsec.net/git/tpserver-cpp.git | 00:02 |
| mithro | llnz: take a look at that? | 00:13 |
| llnz | back, looking | 00:30 |
| CIA-10 | llnz tpserver-cpp * r0fbab3059690 /modules/games/minisec/ (minisec.cpp minisec.h sample.conf): | 00:34 |
| CIA-10 | Moved Names class decl to minisec.cpp, documented new setting. | 00:34 |
| CIA-10 | Just a little clean up. | 00:34 |
| mithro | llnz: How can the createSystems method know about the Names class decl if it's not defined in minisec.hpp? | 00:38 |
| llnz | it knows it's a pointer | 00:38 |
| llnz | and the name of the class | 00:38 |
| llnz | and it still sees the decl before the method itself is compiled | 00:39 |
| llnz | as do all calling methods/functions | 00:39 |
| mithro | okay | 00:40 |
| mithro | those classes probably make sense for a number of rulesets | 00:40 |
| llnz | i know | 00:40 |
| llnz | i will add it to my list of things to do | 00:41 |
| llnz | mithro: does tpserver-py store a copy of each object each turn? | 01:12 |
| mithro | llnz: no | 01:13 |
| llnz | only when it changes? | 01:13 |
| mithro | yes | 01:13 |
| mithro | and then only the changes | 01:13 |
| llnz | indexed on the turn number? | 01:14 |
| llnz | oh | 01:14 |
| mithro | well it will :) | 01:14 |
| mithro | it uses smart sql | 01:14 |
| mithro | so that it only gets the latest "version" of each attribute | 01:15 |
| mithro | players then point to the latest "version" they can see | 01:15 |
| mithro | but this is all in theory | 01:16 |
| mithro | llnz: does that make sense? | 01:18 |
| llnz | yeah | 01:18 |
| mithro | I got part way though implimenting it when I had the accident with rm -rf about 4-5 months ago | 01:18 |
| llnz | hehe | 01:19 |
| llnz | in the short term, i think i'll store a whole copy for changed object | 01:19 |
| mithro | llnz: you can now have much bigger universes on tpserver-cpp with those patches | 01:19 |
| mithro | llnz: it would be nice if you didn't touch every fleet each turn | 01:20 |
| * llnz notes it doesn't take much for an object to change | 01:20 | |
| llnz | every fleet each turn? | 01:20 |
| llnz | if the fleet has no orders, then it won't be touched | 01:20 |
| llnz | if an object changes container, then the object, the previous parent, and the new parent all change | 01:22 |
| mithro | llnz: even static fleets with no orders seem to be touched | 01:24 |
| llnz | humm... i wonder if they get recontainerised each turn... | 01:24 |
| mithro | it's not hugely important at the moment | 01:25 |
| CIA-10 | mithro tpclient-pywx-development * r8948f520b391 /extra/wxFloatCanvas/FloatCanvas.py: Always use the older method which doesn't seem to segfault. | 01:26 |
| CIA-10 | llnz tpserver-cpp * r04e8ebf5fd91 /modules/persistence/mysql/ (5 files): | 01:31 |
| CIA-10 | Removing dead files from TpMysql module. | 01:31 |
| CIA-10 | Please re-run autogen.sh and configure. TpMysql module still not compiling. | 01:31 |
| CIA-10 | llnz tpserver-cpp * rfe79be1d884a /tpserver/ (object.cpp object.h): | 01:39 |
| CIA-10 | Added getter/setter for IGObject's description. | 01:39 |
| CIA-10 | Needed to persist the description. Would also be helpful to set it. | 01:39 |
| mithro | llnz: I wasn't sure where those std::string helper functions should go either | 01:40 |
| llnz | i saw from the comments | 01:41 |
| llnz | i don't really have a place for it currently | 01:41 |
| llnz | will have to think about it | 01:41 |
| mithro | I have a bunch more like "rstrip", "lstrip", "endswith" | 01:41 |
| mithro | makes working with std::strings that little bit easier | 01:42 |
| llnz | ok | 01:43 |
| mithro | it's a bit frustrating that the std::string doesn't have these type of methods | 01:44 |
| CIA-10 | mithro tpclient-pywx-development * rd07ecc4c1ef2 /windows/main/overlays/ (Path.py Systems.py): Put things in the background so that hittesting is suitable fast with 1000's of systems. | 01:49 |
| mithro | llnz: did you hear that nash is coming to lca? | 01:49 |
| llnz | nope, cool! | 01:52 |
| mithro | llnz: so I think we can finalise tp04 at LCA | 02:01 |
| mithro | by then we should have better information about how the object parameter stuff is working | 02:01 |
| mithro | hrm - I think i have found a bug in tpserver-cpp | 02:04 |
| llnz | ok, cool | 02:04 |
| llnz | oh? | 02:04 |
| mithro | 1 ai seems to run fine with 500 systems (each with 1 planet) | 02:05 |
| mithro | but if I get 5 to connect at once, they never seem to be able to download the universe | 02:05 |
| llnz | what appears to be the problem? | 02:06 |
| mithro | and then if I kill the tpsai-py's tpserver-cpp seems to just sit at 100% | 02:06 |
| llnz | anything on tpserver-cpp's console? | 02:07 |
| mithro | just | 02:07 |
| mithro | 2007-11-18 17:40:05 < Error > underlying write, tcp, error is: Bad file descriptor | 02:08 |
| mithro | 2007-11-18 17:40:05 < Error > Socket error writing | 02:08 |
| mithro | I think you are flooding the outgoing buffers? | 02:08 |
| llnz | how many of those pairs of lines do you see? | 02:09 |
| llnz | maybe, but i wouldn't thought so | 02:09 |
| llnz | should be 5 pairs of lines | 02:10 |
| mithro | way more then that | 02:10 |
| llnz | ok | 02:10 |
| mithro | seems to be spending a load of time in | 02:15 |
| mithro | #15 0x0810a6f0 in PlayerAgent::processGetObjectById (this=0x8199e10, frame=0x8415dc8) at playeragent.cpp:229 | 02:15 |
| CIA-10 | llnz tpserver-cpp * r4006b3d4cdb3 /tpserver/playertcpconn.cpp: | 02:16 |
| CIA-10 | Fix mithro's Bad file descriptor on write bug. | 02:16 |
| CIA-10 | Keeps trying to send data after the client has disconnected and incorrect | 02:16 |
| CIA-10 | file descriptor set (along with status =0) | 02:16 |
| llnz | i think you might be pipelining too much | 02:16 |
| mithro | llnz: hrm? | 02:16 |
| llnz | but that should help | 02:16 |
| mithro | why does one tpsai-py take about 5-10 seconds | 02:18 |
| mithro | while 5 ai's never seem to finish? | 02:18 |
| llnz | if all the requests arrive at the same time, then the first request from each client is processed | 02:18 |
| llnz | return frames are queued if they can't be sent immediately (non-blocking write) | 02:19 |
| llnz | in the next cycle (select loop), the next client request is processed and the writes done, if possible | 02:19 |
| llnz | etc | 02:19 |
| * llnz wonders if the writes happen first, or the reads | 02:19 | |
| mithro | llnz: but it should still only take a minute or two right? | 02:20 |
| llnz | yeah | 02:20 |
| mithro | are you dequeueing a bunch of packets at once | 02:20 |
| llnz | write queue is processed first... | 02:20 |
| mithro | or just a single one? | 02:20 |
| mithro | tpserver-cpp isn't consuming a massive amount of memory or anything | 02:21 |
| llnz | as many as possible, until given EWOULDBLOCK | 02:21 |
| mithro | llnz: shouldn't you be using a stl list rather then a stl set? | 02:22 |
| llnz | order is not important, but uniqueness is, hence 'set' | 02:23 |
| mithro | it seems to be spending a lot of time balancing the red-black tree that impliments a set | 02:23 |
| mithro | a set is a log(n) insertion and removal | 02:23 |
| llnz | whereas list is O(n) for insertion and removal where uniqueness is important | 02:24 |
| mithro | why is uniqueness important? | 02:25 |
| llnz | btw: which set are we talking about? | 02:25 |
| mithro | #15 0x080cdb48 in _Rb_tree (this=0xbfeaa9d0, __x=@0x81833ac) at /usr/include/c++/4.1.3/bits/stl_tree.h:570 | 02:26 |
| mithro | #16 0x080cdbe0 in set (this=0xbfeaa9d0, __x=@0x81833ac) at /usr/include/c++/4.1.3/bits/stl_set.h:208 | 02:26 |
| mithro | #17 0x08113b7c in PlayerView::getVisibleObjects (this=0x81833a8) at playerview.cpp:108 | 02:26 |
| mithro | #15 0x080cdfd8 in _Rb_tree (this=0xbfd42050, __x=@0x82b1e6c) at /usr/include/c++/4.1.3/bits/stl_tree.h:570 | 02:29 |
| mithro | #16 0x080ce070 in set (this=0xbfd42050, __x=@0x82b1e6c) at /usr/include/c++/4.1.3/bits/stl_set.h:208 | 02:29 |
| mithro | #17 0x0811488c in PlayerView::getVisibleObjects (this=0x82b1e68) at playerview.cpp:108 | 02:29 |
| mithro | everytime I do a ctrl-C it seems to end up there | 02:31 |
| mithro | any idea why? | 02:32 |
| llnz | odd | 02:34 |
| llnz | oh, it returns a copy of the set | 02:36 |
| llnz | that method is hit everytime there is something to do with getting an object, or the list of object ids | 02:36 |
| CIA-10 | llnz tpserver-cpp * r06bd5bb5371e /tpserver/playeragent.cpp: | 02:40 |
| CIA-10 | Don't grab a copy of the list if you can just ask if the object exists. | 02:40 |
| CIA-10 | In PlayerAgent::processGetObjectById, don't get the list of visible object | 02:40 |
| CIA-10 | ids to see if the object is visible, just directly ask PlayerView if it is | 02:40 |
| CIA-10 | visible. Should make Get Object (by id) frames faster. | 02:40 |
| llnz | try that, should help | 02:41 |
| mithro | llnz: testing now | 02:43 |
| mithro | llnz: you could test locally to see if you can get the same results? | 02:45 |
| mithro | llnz: I'm wondering if maybe there is a bug in the libtpproto-py code which is causing it to continually re-send the frame | 02:46 |
| llnz | will test here shortly | 02:55 |
| mithro | okay | 02:56 |
| mithro | llnz: atleast it isn't getting stuck in the same place... | 02:56 |
| llnz | ok | 02:57 |
| mithro | ohh... got a segfault | 03:01 |
| mithro | weird | 03:01 |
| mithro | 2007-11-18 18:35:06 < Info > Accepting new tp (tcp) connection | 03:01 |
| mithro | tpserver-cpp> turn end | 03:01 |
| mithro | Program received signal SIGSEGV, Segmentation fault. | 03:01 |
| mithro | [Switching to Thread -1212881216 (LWP 14735)] | 03:01 |
| mithro | 0x082de46d in ?? () | 03:01 |
| mithro | (gdb) bt | 03:02 |
| mithro | #0 0x082de46d in ?? () | 03:02 |
| mithro | #1 0x080c172f in Network::masterLoop (this=0x813c278) at net.cpp:325 | 03:02 |
| mithro | #2 0x080b1d44 in main (argc=3, argv=0xbfd46494) at main.cpp:135 | 03:02 |
| mithro | (gdb) cont | 03:02 |
| llnz | fun | 03:02 |
| llnz | ok, normal number of planets is working ok for me | 03:04 |
| mithro | normal numbers work fine | 03:05 |
| mithro | it's just with 500 planets or more | 03:05 |
| mithro | and a single ai works fine | 03:06 |
| mithro | it's just 5 ais | 03:06 |
| llnz | hehe, have a look at the metaserver :-) | 03:07 |
| mithro | Okay I turned on debugging on the ai | 03:11 |
| mithro | and it seems something to do with the order downloads | 03:11 |
| llnz | one of the libraries tries getting the orders for *every* object | 03:12 |
| llnz | oh | 03:14 |
| mithro | oh? | 03:14 |
| llnz | and i think you are trying to get all the objects at the same time | 03:14 |
| llnz | myabe? | 03:14 |
| mithro | it is sending an order request for every object | 03:15 |
| mithro | but again, 1 ai works | 03:15 |
| llnz | ie, a getObjectsById with every id in it | 03:15 |
| mithro | multiple don't | 03:15 |
| llnz | hehe, tpserver-cpp using 1059M virt, 871M res | 03:16 |
| llnz | tpsai-py 80-104M virt, 28-35M res | 03:17 |
| llnz | swap *is* being used | 03:17 |
| mithro | why? | 03:20 |
| llnz | i don't know what's going on | 03:20 |
| mithro | when I sort by memory tpserver-cpp doesn't even show up on my laptop | 03:21 |
| llnz | odd | 03:24 |
| llnz | i've restarted with just one ai this time, and it's really up to 1GB | 03:24 |
| llnz | (res) | 03:24 |
| mithro | not seeing that at all locally | 03:26 |
| mithro | how many planets/systems? | 03:26 |
| llnz | odd | 03:26 |
| mithro | I have 500 planets, 1 per system | 03:26 |
| llnz | 500 systems, 1 or 2 planets per system | 03:26 |
| llnz | i'm seeing a lot of "Read data not the length needed, delaying read" messages | 03:29 |
| mithro | where? | 03:30 |
| llnz | netstat -l suggests that tpserver-cpp is reading data quicker than tpsai-py is sending | 03:31 |
| llnz | tpserver-cpp log messages | 03:31 |
| mithro | llnz: maybe I should turn on debugging | 03:31 |
| mithro | (on tpserver-cpp) | 03:31 |
| llnz | yeah, maybe | 03:31 |
| llnz | ouch, over 327678 frames in the send queue | 03:36 |
| mithro | wow :P | 03:37 |
| llnz | yeah | 03:37 |
| mithro | why is there that many? | 03:37 |
| *** peres has joined #tp | 03:37 | |
| llnz | takes a while to delete them | 03:37 |
| llnz | humm... no iidea | 03:37 |
| llnz | maybe an EOT starrtedd the process again | 03:37 |
| mithro | I'm seeing some strange results | 03:40 |
| llnz | so am i | 03:40 |
| llnz | the send queue isn't getting smaller over time | 03:41 |
| mithro | like I have all the objects and still have many kilobytes of data still in the buffer | 03:41 |
| mithro | [01;31mReceived: \xff\xebo\xb7\xc0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00k\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00G\x3f\xf6\x24\x00\x00\x00\x00\x00\x00\x00\x00TP03\x00\x00\x00\x29\x00\x00\x00\x07\x00\x00\x00\x7b\x00\x00\x00k\x00\x00\x00\x03\x00\x00\x00\x13System 47\x2c Planet 1\x00\x00\x00\x00\x00\x00\x00\x02\xff\xff\x | 03:44 |
| mithro | ff\xffkY0\xc0\xff\xff\xff\xff\xebo\x2f\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 | 03:44 |
| mithro | [0mRecieved Left: 152985 | 03:44 |
| mithro | _recvBytes-s 168 False 152985 | 03:44 |
| mithro | _recvBytes-e 168 False 152817 | 03:44 |
| mithro | [01;31mReceiving: <Fleet @ 1012> | 03:44 |
| mithro | why would I be receiving things which reference "System 47 Planet 1" when I have just recieved Fleet 1012? | 03:45 |
| peres | stupid suggestion: are you guys using tcp or udp for connection? | 03:46 |
| llnz | tcp | 03:46 |
| peres | ok, so it's reliable order | 03:47 |
| llnz | yes | 03:47 |
| peres | can it be overflowing (and thus overwriting) previous stuff in the circular buffer? | 03:48 |
| llnz | shouldn't be | 03:48 |
| llnz | the frames appear to be arriving intact | 03:48 |
| peres | well, overflowing should happen on your side, not on server's | 03:49 |
| peres | so packets would arrive in good health | 03:49 |
| mithro | oh, I think I may have found atleast one bug in libtpproto-py | 03:50 |
| mithro | yeah, I have found a bug in libtpproto-py | 03:52 |
| mithro | if frames are bigger then the buffer length | 03:52 |
| * peres feels so proud of his intuition :P | 03:53 | |
| mithro | peres: well, it's unrelated to overflowing/underflowing | 03:55 |
| peres | ok ok, just trying to pretend | 03:55 |
| mithro | just a stupid logic error | 03:55 |
| mithro | llnz: it appears it was my fault | 03:55 |
| peres | on the other way, if your frame doesn't fit in your buffer, that is called overflow :P | 03:55 |
| mithro | peres: the problem was the following code | 03:58 |
| mithro | llnz: give that a shot | 03:59 |
| CIA-10 | mithro libtpproto-py * r99c9176347e3 /tp/netlib/common.py: Always remove a packet when we queue it (instead only if we sent enough data). | 03:59 |
| mithro | peres: I put the pop from a queue in the wrong place | 04:00 |
| peres | i see | 04:00 |
| mithro | I queued the frame, checked to see if I had space to queue more frames and then poped the queued frame | 04:02 |
| mithro | instead of | 04:02 |
| mithro | I queued the frame, poped the queued frame, checked to see if I had space to queue more frames | 04:02 |
| mithro | llnz: ping? | 04:09 |
| llnz | pong | 04:10 |
| peres | i was looking at the video in the subject: are those changing lights planets being conquered by different races? | 04:11 |
| llnz | mithro: that made a big difference | 04:15 |
| llnz | peres: each colour is a different player, and when an area is lit up, the planet in the middle is controlled by the player who's colour it is | 04:16 |
| llnz | so, yet | 04:16 |
| llnz | s/yet/yes/ | 04:16 |
| mithro | llnz: cool | 04:16 |
| peres | is it on fast forward? or is the game so fast? | 04:16 |
| mithro | llnz: i want to do a 1000 planet battle with 5 ai soon | 04:17 |
| mithro | with recording the positions | 04:17 |
| mithro | peres: it's on 10 turns per second | 04:17 |
| llnz | mithro: cool | 04:17 |
| llnz | i have started 5 ai on my 500 system (approx 750 planets) | 04:17 |
| mithro | okay | 04:19 |
| llnz | will (either) tpclient-pywx handle that universe? | 04:21 |
| mithro | yeah, both should | 04:22 |
| mithro | tpclient-pywx stable looks very cluttered | 04:22 |
| mithro | tpclient-pywx-dev seems to work a bit better, but it quite a bit slower (i'm yet to optomise it) | 04:23 |
| llnz | very cluttered is a bit of an understatement | 04:23 |
| mithro | llnz: just zoom in a bit :) | 04:23 |
| llnz | yeah | 04:23 |
| mithro | the dev client is a bit better to use in that regard | 04:24 |
| *** _peres_ has joined #tp | 04:26 | |
| *** peres has quit IRC | 04:26 | |
| *** _peres_ is now known as peres | 04:26 | |
| peres | i'm trying the python client, but i get an error from requirement.py | 04:29 |
| peres | NameError: name 'system' is not defined | 04:29 |
| peres | i'm on windows | 04:29 |
| mithro | peres: from git? | 04:35 |
| peres | no, website | 04:35 |
| mithro | exe file? | 04:38 |
| mithro | or source? | 04:38 |
| mithro | if you are trying source then you should probably use git/cvs | 04:39 |
| peres | i downloaded the source code | 04:39 |
| mithro | yeah, the source code probably doesn't run on windows | 04:40 |
| mithro | http://www.thousandparsec.net/wiki/Win_Setup | 04:40 |
| tpb | Title: Win Setup - Thousand Parsec Wiki (at www.thousandparsec.net) | 04:40 |
| mithro | give that a try? | 04:40 |
| mithro | bblr dinner | 04:40 |
| llnz | 196 planets conquered so far | 04:45 |
| llnz | 230 | 04:46 |
| llnz | 260 | 04:49 |
| llnz | 300 | 04:52 |
| llnz | it takes a few seconds to do the end of turn now | 04:54 |
| llnz | 350 | 04:55 |
| llnz | turn started :32 | 04:59 |
| llnz | move processing finished :34 | 05:00 |
| llnz | combat started :36 | 05:00 |
| llnz | turn finished :36 | 05:00 |
| llnz | 410 | 05:00 |
| llnz | 4 seconds to do the end of turn | 05:02 |
| llnz | just had the turn length longer as the AI's don't appear to be keeping up | 05:02 |
| llnz | (from 90 to 120 seconds) | 05:02 |
| llnz | 460 | 05:03 |
| llnz | 530 | 05:10 |
| llnz | nearly 2000 objects in play | 05:10 |
| mithro | llnz: yeah, the tpsai-py is not very efficent | 05:15 |
| llnz | neither is tpserver-cpp | 05:15 |
| mithro | anyway, gf is over so have to run | 05:15 |
| llnz | ok, cya | 05:15 |
| mithro | tpsai-py is very inefficent :P | 05:15 |
| mithro | tpclient-pywx isn't too bad | 05:15 |
| llnz | 580 planets | 05:16 |
| mithro | tpserver-py is pretty good (apart from turn processing) | 05:16 |
| llnz | turn processing is getting slower and slower | 05:16 |
| llnz | especially the setup for combat (finding the combat areas) | 05:17 |
| mithro | it should only be order n? | 05:18 |
| llnz | about nlogn i think | 05:20 |
| llnz | it's basically a massive search | 05:20 |
| llnz | a lot of the time, the result is thrown away because there is no combat | 05:21 |
| llnz | going to have to think about it some more | 05:21 |
| llnz | "The Universe currently has 2072 objects" | 05:22 |
| llnz | 620 planets | 05:24 |
| llnz | oh, i have a pywx-dev screen shot, btw | 05:25 |
| mithro | upload it to your public_html :P | 06:21 |
| llnz | will do | 06:21 |
| llnz | http://code.thousandparsec.net/~lee/tpserver-cpp-starmap-pywx-dev-500-sys.png | 06:23 |
| tpb | <http://ln-s.net/1-C6> (at code.thousandparsec.net) | 06:23 |
| llnz | http://code.thousandparsec.net/~lee/tpserver-cpp-starmap-pywx-dev-500-sys2.png | 06:23 |
| tpb | <http://ln-s.net/1-C7> (at code.thousandparsec.net) | 06:23 |
| llnz | "The Universe currently has 2432 objects" | 06:25 |
| llnz | (according to the metaserver) | 06:26 |
| *** peres has quit IRC | 06:29 | |
| * llnz wanders off | 06:35 | |
| llnz | later all | 06:35 |
| *** llnz has quit IRC | 06:35 | |
| mithro | http://www.thousandparsec.net/~tim/tparsec-llnz-58.png | 07:13 |
| tpb | <http://ln-s.net/1-CM> (at www.thousandparsec.net) | 07:13 |
| *** TBBle_ has joined #tp | 08:24 | |
| *** TBBle has quit IRC | 08:25 | |
| *** TBBle_ is now known as TBBle | 08:29 | |
| *** mithro has quit IRC | 09:05 | |
| *** TBBle has quit IRC | 11:10 | |
| *** TBBle has joined #tp | 11:10 | |
| CIA-10 | jezuch libtpproto-java-experimental * r9cc9b9a678be /src/net/thousandparsec/netlib/PipelinedConnection.java: | 11:40 |
| CIA-10 | Improve exception handling in PipelinedConnection. Distinguish between protocol errors and I/O errors - the latter are final while the former leave a chance that the connection can continue. | 11:40 |
| CIA-10 | As a bonus, close the connection when the receiver quits. | 11:40 |
| CIA-10 | jezuch libtpproto-java-experimental * rdacf6e344c77 /build.xml: Compile with debugging information. | 11:40 |
| CIA-10 | jezuch libtpproto-java-experimental * r6fe3144eeec0 /src/net/thousandparsec/netlib/PipelinedConnection.java: | 11:40 |
| CIA-10 | Use correct close() method and try to avoid deadlock when the receiver task is exiting (not tested!) (but rare, I hope for some unlucky guinea pig to hit this ;)) | 11:40 |
| CIA-10 | And in the process remove InterruptedException from throws clause of PipelinedConnection.close(). | 11:40 |
| CIA-10 | jezuch libtpproto-java-experimental * r21ac29101c72 /src/net/thousandparsec/netlib/PipelinedConnection.java: The receiver task's ExecutorService does not need to be stroed in an instance field. | 11:40 |
| CIA-10 | jezuch libtpproto-java-experimental * r5bf6739281f9 /src/net/thousandparsec/netlib/PipelinedConnection.java: final frenzy! | 11:40 |
| CIA-10 | jezuch libtpproto-java-experimental * rdc5b79d7113c /src/net/thousandparsec/netlib/PipelinedConnection.java: Barf if the PipelinedConnection's pipeline is closed and someone tries to use it. | 11:40 |
| CIA-10 | jezuch libtpproto-java * r12d01ae2ff76 /src/net/thousandparsec/netlib/PipelinedConnection.java: | 11:41 |
| CIA-10 | Improve exception handling in PipelinedConnection. Distinguish between protocol errors and I/O errors - the latter are final while the former leave a chance that the connection can continue. | 11:41 |
| CIA-10 | As a bonus, close the connection when the receiver quits. | 11:41 |
| CIA-10 | jezuch libtpproto-java * rdb0843cea2ee /build.xml: Compile with debugging information. | 11:41 |
| CIA-10 | jezuch libtpproto-java * r7024984e118b /src/net/thousandparsec/netlib/PipelinedConnection.java: | 11:41 |
| CIA-10 | Use correct close() method and try to avoid deadlock when the receiver task is exiting (not tested!) (but rare, I hope for some unlucky guinea pig to hit this ;)) | 11:41 |
| CIA-10 | And in the process remove InterruptedException from throws clause of PipelinedConnection.close(). | 11:41 |
| CIA-10 | jezuch libtpproto-java * r95b14f9fec33 /src/net/thousandparsec/netlib/PipelinedConnection.java: The receiver task's ExecutorService does not need to be stroed in an instance field. | 11:41 |
| CIA-10 | jezuch libtpproto-java * r84650ce3a930 /src/net/thousandparsec/netlib/PipelinedConnection.java: final frenzy! | 11:41 |
| CIA-10 | jezuch libtpproto-java * r3339c674f883 /src/net/thousandparsec/netlib/PipelinedConnection.java: Barf if the PipelinedConnection's pipeline is closed and someone tries to use it. | 11:41 |
| *** peres has joined #tp | 12:00 | |
| *** peres has quit IRC | 13:47 | |
| *** peres has joined #tp | 14:38 | |
| CIA-10 | jlp libtpproto-cpp * rdea149e30c4b /tpproto/message.cpp: Fixed compilation | 14:52 |
| *** JLP has joined #tp | 15:19 | |
| JLP | ahoy all, long time no see | 15:21 |
| *** nash has joined #tp | 16:21 | |
| *** peres has left #tp | 16:56 | |
| *** mithro has joined #tp | 16:59 | |
| *** mithro has quit IRC | 17:42 | |
| *** mithro has joined #tp | 18:14 | |
| mithro | ~seen ll | 18:16 |
| tpb | mithro: I have not seen ll. | 18:16 |
| mithro | ~seen llnz | 18:16 |
| tpb | mithro: llnz was last seen in #tp 11 hours, 41 minutes, and 6 seconds ago: <llnz> later all | 18:16 |
| mithro | ~seen JLP | 18:16 |
| tpb | mithro: JLP was last seen in #tp 2 hours, 54 minutes, and 46 seconds ago: <JLP> ahoy all, long time no see | 18:16 |
| mithro | JLP: ping? | 18:16 |
| mithro | hey nash | 18:16 |
| mithro | good to see the status report | 18:16 |
| mithro | so you have a new toy that you are not allowed to talk about? | 18:16 |
| JLP | mithro: pong | 18:17 |
| mithro | JLP: did you ever get anywhere with the qtopia stuff? | 18:18 |
| JLP | mithro: looks like it's cursed | 18:18 |
| mithro | JLP: :(, what happened this time? | 18:19 |
| nash | Heyo mithro | 18:19 |
| nash | mithro: Thanks | 18:19 |
| nash | I take it it got through then | 18:20 |
| mithro | nash: yeah, got through fine - apart from my mail server sitting at a load of 22 :/ | 18:20 |
| JLP | mithro: the phone died on me, i left it connected to USB port and the battery drained out | 18:20 |
| mithro | JLP: ouch :( | 18:20 |
| JLP | mithro: so i had to order a new battery | 18:21 |
| mithro | can you develop just using the sdk? | 18:21 |
| JLP | mithro: yeah it would be possible but i also didn't and this is another story keepinf me away from developing | 18:23 |
| JLP | mithro: i've had problems with my new medications for epilepsy, so ifor the last week or two i was feeling quite dizzy all day, so I had to be at the hospital for most of the days for observations | 18:24 |
| JLP | mithro: now they gave me the drugs that don't have strange effects on me and the blood tests are fine so i hope all will be fine from now on | 18:24 |
| mithro | nash: btw, did you see that I fixed minisec so you can have larger universes? | 18:25 |
| nash | Yeah | 18:25 |
| nash | Testing with large universes will begin again I'm sure... | 18:25 |
| mithro | dang, looks like llnz's server crashed.... | 18:25 |
| mithro | he had about 2700 objects last time I checked | 18:25 |
| mithro | http://www.thousandparsec.net/~lee/tpserver-cpp-starmap-pywx-dev-500-sys.png | 18:26 |
| tpb | <http://ln-s.net/1-HJ> (at www.thousandparsec.net) | 18:26 |
| mithro | http://www.thousandparsec.net/~lee/tpserver-cpp-starmap-pywx-dev-500-sys2.png | 18:26 |
| tpb | <http://ln-s.net/1-HK> (at www.thousandparsec.net) | 18:26 |
| mithro | http://www.thousandparsec.net/~tim/Screenshot.png | 18:26 |
| tpb | <http://ln-s.net/Z2z> (at www.thousandparsec.net) | 18:26 |
| mithro | http://www.thousandparsec.net/~tim/tparsec-llnz-58.png | 18:26 |
| tpb | <http://ln-s.net/1-CM> (at www.thousandparsec.net) | 18:26 |
| mithro | JLP: you see the movie in the topic? | 18:26 |
| JLP | mithro: yup, looks very cool | 18:27 |
| JLP | mithro: holy crap now that's a lot of objects | 18:27 |
| mithro | tpclient-pywx seems to handle it okay - but not as well as I would like | 18:28 |
| JLP | mithro: this stuff would overload the phone i guess :) | 18:29 |
| mithro | JLP: what type of memory do you have? tpsai-py is happily sitting at 14mb with the whole universe in memory | 18:31 |
| JLP | mithro total memory:62304 kB | 18:32 |
| mithro | I think if you where clever it would work okay | 18:34 |
| mithro | nash: found a nasty bug in libtpproto-py which was causing it to send a frame multiple times | 18:34 |
| nash | Lovely | 18:34 |
| nash | Any frame, or just some? | 18:34 |
| mithro | but only under very heavily load | 18:34 |
| mithro | nash: it occurs when you managed to flood the outgoing tcp socket buffer | 18:35 |
| nash | Hmm... | 18:35 |
| nash | I'm surprised I didn't hit it | 18:36 |
| mithro | http://git.thousandparsec.net/gitweb/gitweb.cgi?p=libtpproto-py.git;a=commitdiff;h=99c9176347e35c7d607c7cf1b7ed7f22e8ca550e | 18:36 |
| tpb | <http://ln-s.net/1-HS> (at git.thousandparsec.net) | 18:36 |
| mithro | nash: I'm a supprised that people have not hit it before | 18:36 |
| JLP | mithro: i doubt i would be clever enough, but with help from more experinced people here it's another story :) | 18:37 |
| nash | mithro: Well most of galaxie doesn't care if it gets the same frame twice | 18:37 |
| mithro | nash: it took 5 ais with 2700 objects in the universe before that bug appeared | 18:37 |
| mithro | nash: it's a bug in the client not the server | 18:38 |
| nash | Ahh | 18:38 |
| nash | Then I'd never hit it ;-) | 18:38 |
| JLP | hmm i get this error when i try to push: | 18:38 |
| JLP | fatal: '/git/parsek.git#objectsmodel': unable to chdir or not a git archive | 18:38 |
| JLP | fatal: The remote end hung up unexpectedly | 18:38 |
| JLP | error: failed to push to 'git+ssh://[email protected]/git/parsek.git#objectsmodel | 18:38 |
| mithro | hrm... | 18:40 |
| JLP | or maybe i forgot how to push to a remote branch or something | 18:41 |
| mithro | JLP: did you remeber to load you ssh key? | 18:42 |
| JLP | from local branch i just did "git-push r-objectsmodel" if that is ok | 18:43 |
| JLP | mithro: it did ask me for Passkey and accepted it | 18:43 |
| mithro | oh, the #<branchname> is a cogito only thing | 18:43 |
| JLP | mithro: oooh, damn, so i forgot i was using cogito, let's try with it | 18:44 |
| JLP | it looks like it worked, i can see it on the web, despite there was this line "XML-RPC Error:" printed out 8 times | 18:52 |
| CIA-10 | nash galaxie * r9851009d4c70 /ewl/gewl_object.c: Basic listing of possible orders in the order list | 19:07 |
| CIA-10 | nash galaxie * rf4e9ae8250c3 /ewl/gewl_object.c: | 19:07 |
| CIA-10 | Commented out functiosn for toggling resource list when not in use. | 19:07 |
| CIA-10 | Unfortunately it appears EWL is broken for this. | 19:07 |
| CIA-10 | nash galaxie * r7bfcdcdb48e6 /server.c: Add some extra asserts to server magic. | 19:07 |
| CIA-10 | nash galaxie * r3d92276182e1 /tpe_comm.c: Don't free server structure on turn end... that's bad. | 19:07 |
| CIA-10 | nash galaxie * r77bc57b988a4 /tpe_event.c: Assert before shooting myself in the foot. | 19:07 |
| CIA-10 | nash galaxie * r3f94a41edb3b /ewl/gewl_object.c: First generation handler for selection planets. | 19:07 |
| CIA-10 | nash galaxie * r84c384668df4 /tpe_gui.c: Fix ghandling of time remaining messages in the GUI. | 19:07 |
| CIA-10 | nash galaxie * rfa4528294827 / (tpe_orders.c tpe_orders.h): Move order desc to public interface of tpe_orders. | 19:07 |
| CIA-10 | nash galaxie * rc67d28b6866f /ewl/gewl_object.c: Start of work on args for orders. | 19:07 |
| CIA-10 | nash galaxie * r8aadf1640c8c /ewl/gewl_object.c: Make selection of tree possible. | 19:07 |
| CIA-10 | nash galaxie * rdccf051c4324 /ewl/gewl_object.c: Add basic handling for most order types. | 19:07 |
| mithro | JLP: yeah, first time you push a branch everything goes a bit skiso | 19:12 |
| mithro | nash: so is galaxie at a stage where others can start testing it? | 19:13 |
| nash | mithro: Not yet | 19:15 |
| nash | At the end of the week, hopefully | 19:15 |
| mithro | wow, no wonder tpclient-pywx is slow | 19:15 |
| mithro | it's drawing the starmap about 400 times on a click | 19:16 |
| mithro | yay for broken code | 19:18 |
| nash | Can't be great | 19:20 |
| mithro | well, I FloatCanvas has been shown to handle drawing around 50,000 objects pretty easily | 19:23 |
| mithro | and we are only up to about 3000-4000 objects | 19:23 |
| mithro | and getting annoying flicker | 19:23 |
| mithro | nash: you see the starmapper email? | 19:25 |
| nash | the new version one | 19:25 |
| nash | mithro: As for galaxie.. it is stable again. Any crashes now are unexpected | 19:58 |
| nash | And it can be used to browse the map happily | 19:58 |
| nash | the AIs are all disabled | 19:59 |
| CIA-10 | jlp parsek-objectsmodel * re60bd160bab9 /src/CMakeLists.txt: Removed kde4_automoc() - not needed anymore | 20:33 |
| CIA-10 | jlp parsek-objectsmodel * r0fa2fed26435 /src/ (loggerwidget.cpp loggerwidget.h): | 20:33 |
| CIA-10 | Compile with libtpproto-cpp from git | 20:33 |
| CIA-10 | Arguments in virtual functions in logger are now const | 20:33 |
| mithro | yay JLP :) | 20:36 |
| JLP | mithro: just keeping TP on the list of most active projects today on CIA :) | 20:41 |
| nash | JLP: So... smaller commits hey? | 20:44 |
| JLP | nash: yup, a little cleaning before i move on | 20:48 |
| nash | JLP: Question: Why are you removing 'const' from teh char*? Gengeally you want add them | 21:02 |
| JLP | nash: i don't remember removing it | 21:07 |
| nash | JLP: The last commit message jsut before mithro said "yay JLP" | 21:08 |
| JLP | nash: in this one i just added it, the last time i compiled with libtpproto-cpp downloaded from the site and back then there were no consts there, now in git version consts are there so i also had to add them otherwise it wouldn't match | 21:11 |
| * nash slaps self | 21:11 | |
| nash | Sorry, misread the patch | 21:11 |
| nash | You are gith | 21:12 |
| nash | s/right/ | 21:12 |
| JLP | nash: ok then, i was afraid i did something stupid again | 21:12 |
| mithro | muhahaha -> http://www.hugeurl.com/ :P | 21:12 |
| tpb | Title: HugeURL (at www.hugeurl.com) | 21:12 |
| JLP | nash: if you look at the about 3 commits back, a bit larger one, there you will rpobably find lots of silly things :) | 21:13 |
| nash | JLP: Nah... then you'd look at mine, and it would be much worse ;-) | 21:14 |
| nash | Anyway... lunch! | 21:26 |
| mithro | why is it so hard to do simple things in C++? | 23:16 |
| *** nash has quit IRC | 23:17 | |
| *** nash has joined #tp | 23:25 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!
