| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| * llnz is back | 00:16 | |
| *** tansell-laptop has quit IRC | 00:29 | |
| *** mithro has quit IRC | 00:29 | |
| *** verhoevenv has quit IRC | 01:57 | |
| *** nash has joined #tp | 02:09 | |
| alanp | llnz: ping | 03:04 |
|---|---|---|
| llnz | hi alanp | 03:04 |
| alanp | hey, i have a bad commit/merge on the mtsec branch | 03:04 |
| alanp | 4364880ef74cec50807120b71f8ce321fe378f48 | 03:04 |
| alanp | i need to nuke it, without any kind of "meltdown" | 03:04 |
| alanp | :( | 03:05 |
| ezod | did you read that thing i sent you? | 03:07 |
| alanp | i'm trigger shy, just had a git meltdown on my end | 03:07 |
| ezod | you can try doing the appropriate surgery as per that article, and inspect the branches locally, without pushing | 03:08 |
| alanp | is it going to send cia-29 batshit crazy? | 03:08 |
| ezod | so if you jack it all up you can rm -rf and fresh commit ;) | 03:09 |
| ezod | err checkout | 03:09 |
| ezod | i don't think it will generate a lot of commit messages | 03:09 |
| ezod | read the article very carefully | 03:09 |
| alanp | send it again? | 03:09 |
| ezod | http://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt | 03:10 |
| tpb | <http://ln-s.net/33i9> (at www.kernel.org) | 03:10 |
| ezod | it's describing almost your situation | 03:11 |
| ezod | except in their case it's the mainline that merged a feature branch and they want to kick it out (but still be able to merge it in later, with all pre-screwup commits included) | 03:12 |
| ezod | whereas you have merged master into mtsec and want to undo that | 03:12 |
| alanp | hmm | 03:12 |
| llnz | what's the problem that merging master has introduced? | 03:17 |
| *** tansell-laptop has joined #tp | 03:17 | |
| ezod | llnz: that was my first question also | 03:19 |
| ezod | alanp: i don't recall your response | 03:19 |
| alanp | mtsec functions incorrectly on master | 03:20 |
| alanp | lots of stuff broken :( | 03:20 |
| alanp | null has been working from mtsec branch, i figure once we get everything fixed in master we can always backport from mtsec | 03:20 |
| alanp | comments? | 03:23 |
| llnz | alanp: we can create a new branch to start merging the mtsec branch into master, and pick the commits from the mtsec branch into it | 03:24 |
| alanp | hmm | 03:25 |
| alanp | we would have to merge epyon changes manually | 03:25 |
| alanp | that's where i think it went wrong? | 03:25 |
| llnz | or branch an earlier version of the mtsec branch off to something stable for now | 03:25 |
| alanp | i guess i could take mtsec before the merge and call it null? | 03:25 |
| ezod | how do you get mtsec "before the merge" though? | 03:26 |
| alanp | commit 39b81eb414e3666b9cb9d15eae259db709fb836d, no? | 03:27 |
| alanp | no, would have to go further back | 03:27 |
| ezod | the problem is all the commits from master are interleaved in with mtsec now | 03:27 |
| alanp | ?? | 03:27 |
| alanp | couldn't i checkout f5d41b9135a69f8053eddc47a0e9212aee0ecbc1 | 03:28 |
| * llnz wishes he was in linux right now and could run qgit and gitk to see what is what | 03:28 | |
| alanp | gitk, eh | 03:29 |
| ezod | qgit shows that nice "tree" thing on the left side | 03:29 |
| ezod | very handy | 03:29 |
| alanp | gitk kinda ugly | 03:30 |
| ezod | alanp: that article explains what to do, no? | 03:30 |
| ezod | i don't think there's an easier way that won't mess anything up down the road | 03:30 |
| alanp | hmm | 03:33 |
| llnz | hang on | 03:33 |
| alanp | i can't "Reset to here"? | 03:33 |
| llnz | nope, don't mind me | 03:34 |
| ezod | you can, but are all the unwanted commits from master chronologically after the latest commit (besides the merge) in mtsec? | 03:34 |
| alanp | no don't think so :( | 03:35 |
| alanp | article, kind of confusing | 03:35 |
| ezod | you will learn a lot about git ;) | 03:35 |
| alanp | making my head spin :P | 03:36 |
| llnz | maybe we should just be fixing the code instead? | 03:40 |
| ezod | i think llnz is onto something ;) | 03:40 |
| alanp | time problems | 03:41 |
| llnz | it will have to be done anyway | 03:41 |
| alanp | but yes, i like that idea | 03:41 |
| alanp | null is stuck until i can fix a couple issues for him, so my priority is to get him working ASAP | 03:41 |
| alanp | once he is working, i can investigate fixing the actual problems | 03:41 |
| alanp | [mtsec f38c7d8] Revert "Merge branch 'master' of git+ssh://git.thousandparsec.net/git/tpserver-cpp" | 03:43 |
| alanp | 11 files changed, 57 insertions(+), 196 deletions(-) | 03:43 |
| alanp | ugh | 03:43 |
| alanp | it's going to CIA-29 flood, isn't it? | 03:43 |
| ezod | that's only 1 commit.. | 03:44 |
| llnz | nope, should just be one commit | 03:44 |
| alanp | the other one was too | 03:44 |
| CIA-29 | alanp tpserver-cpp-mtsec * rf38c7d8a6c05 /tpserver/ (11 files): | 03:44 |
| CIA-29 | Revert "Merge branch 'master' of git+ssh://git.thousandparsec.net/git/tpserver-cpp" | 03:44 |
| CIA-29 | This reverts commit 4364880ef74cec50807120b71f8ce321fe378f48, reversing | 03:44 |
| CIA-29 | changes made to 39b81eb414e3666b9cb9d15eae259db709fb836d. | 03:44 |
| alanp | hmm | 03:44 |
| ezod | the other one pulled all the actual commits from master in so they fired as commits to mtsec | 03:45 |
| alanp | so it keeps the history in gitweb | 03:45 |
| alanp | http://git.thousandparsec.net/gitweb/gitweb.cgi?p=tpserver-cpp.git;a=shortlog;h=refs/heads/mtsec | 03:45 |
| ezod | now, you have a problem | 03:45 |
| tpb | <http://ln-s.net/7C46> (at git.thousandparsec.net) | 03:45 |
| ezod | apparently, if i make a commit to tpserver-cpp master now | 03:45 |
| ezod | and you merge master into mtsec again | 03:46 |
| ezod | you will only see the new commit | 03:46 |
| ezod | i.e. the commits previous to the merge will not merge back in | 03:46 |
| ezod | according to the article | 03:46 |
| alanp | ok | 03:47 |
| llnz | nothing you reverted should have been causing a problem | 03:47 |
| ezod | alanp: okay, here's the easy answer | 03:48 |
| ezod | when you want to merge master again later on | 03:48 |
| ezod | revert the commit you just did first | 03:48 |
| llnz | in fact it has some sigiificant bug fixes | 03:48 |
| ezod | i.e. revert the reversion of the merge | 03:48 |
| alanp | llnz: it merged epyon's refactoring changes... | 03:49 |
| llnz | then you have another merge to undo, good luck with that | 03:50 |
| alanp | :( | 03:50 |
| alanp | [12:49:27] <null_000> I think the only thing that works in the mtsec branch and not in the master branch is building stuff on planets... as far as I know | 03:50 |
| alanp | [12:49:55] <null_000> but that was a blocker for me, so I didn't use the master branch much | 03:50 |
| alanp | maybe it isn't such a huge problem then | 03:50 |
| llnz | alanp: have a look at this commit, maybe i got something wrong that you can fix: http://git.thousandparsec.net/gitweb/gitweb.cgi?p=tpserver-cpp.git;a=commit;h=8ff35fed5fc7881cd328f7d7da2df929194db6a0 | 03:52 |
| tpb | <http://ln-s.net/7C48> (at git.thousandparsec.net) | 03:52 |
| alanp | ok | 03:52 |
| alanp | - fleetlist = (ListParameter*) addOrderParameter( new ListParameter("ships", "The type of ship to build", boost::bind( &Build::generateListOptions, this ) ) ); | 03:54 |
| alanp | + fleetlist = (ListParameter*) addOrderParameter( new ListParameter("ships", "The type of ship to build", boost::bind( &BuildFleet::generateListOptions, this ) ) ); | 03:54 |
| alanp | looking into that | 03:55 |
| alanp | should be ok | 03:55 |
| alanp | yeah i see what he means :( | 04:03 |
| *** tansell-laptop has quit IRC | 04:05 | |
| alanp | and my client crashes | 04:09 |
| alanp | http://pastebin.com/k2ZSPZ6y | 04:16 |
| tpb | Title: Displaying graphics/unknown.pn - Anonymous - k2ZSPZ6y - Pastebin.com (at pastebin.com) | 04:16 |
| alanp | TypeError: can't compare datetime.datetime to int | 04:16 |
| alanp | i have to force-close the clients too :( | 04:20 |
| llnz | alanp: control-C on the console also kills it | 04:22 |
| alanp | nod | 04:22 |
| alanp | that's what i meant by forcing it | 04:22 |
| llnz | ah | 04:22 |
| llnz | i note that it is the "Design" cache causing the issue | 04:23 |
| llnz | maybe check the xstruct for Design to make sure it is turning the uint64 timestamp into a datetime | 04:23 |
| llnz | which it shouldn't do soon anyway, going to be serial numbers instead | 04:23 |
| alanp | going to have to figure out why the planet orders aren't making it to the client too | 04:25 |
| alanp | llnz: remind me where the numbers in ObjectQueue OrderParam -> getParameter coem from? | 04:29 |
| llnz | the order the ObjectParams are added to the object param groups and param groups to the object description | 04:31 |
| alanp | 34 group->addParameter(obpT_Resource_List, "Resource List", "The resource list of the resources the planet has available"); | 04:32 |
| alanp | like that? | 04:32 |
| alanp | or when you create a createParameterGroupDesc i guess | 04:33 |
| alanp | and the add-> are the sub numbers | 04:33 |
| alanp | ok | 04:33 |
| alanp | how does the group for the allowed orders come ? | 04:34 |
| alanp | numgroups+1? | 04:34 |
| llnz | ? | 04:34 |
| alanp | for example: | 04:35 |
| alanp | 71 dynamic_cast<OrderQueueObjectParam*>(obj->getParameter(3,1))->setAllowedOrders(allowedlist); | 04:35 |
| llnz | the OrderQueueObjectParam is the 1st paramater of the 3rd parameter group | 04:38 |
| alanp | right | 04:38 |
| alanp | i just noticed that in minisec it's 5,1 | 04:38 |
| alanp | actually, i just can't read :( | 04:39 |
| llnz | the parameter groups are set up slightly differently in minisec | 04:39 |
| tansell | naught magic numbers :( | 04:39 |
| alanp | tansell: :( | 04:39 |
| tansell | s/naught/naughty/ | 04:39 |
| llnz | tansell: i know, will fix eventually | 04:39 |
| alanp | so it looks like the orders are created, but they never end up at the client | 04:39 |
| llnz | have to run, if you can find a way to reliably reproduce the bug(s), email it too me and i'll have a look when i have time | 04:41 |
| llnz | bbl (hopefully) | 04:41 |
| *** llnz has quit IRC | 04:41 | |
| alanp | think it's a server issue | 04:44 |
| *** llnz has joined #tp | 06:11 | |
| *** cahirwpz has joined #tp | 06:39 | |
| *** bisc has joined #tp | 06:54 | |
| *** llnz2 has joined #tp | 07:02 | |
| *** llnz has quit IRC | 07:02 | |
| *** llnz2 is now known as llnz | 07:09 | |
| bisc | tansell: ping | 07:31 |
| tansell | bisc, pong | 07:31 |
| bisc | tansell: we need to decide something about this patch http://codereview.mithis.com/78001. This bug needs to be solved somehow, so that I can use results. | 07:32 |
| bisc | tansell: I think that this bug emerged because of just outdated code. I've seen some places where code is good but just doesn't correspond to existing data. | 07:34 |
| tansell | bisc, I still don't understand why your code works | 07:39 |
| tansell | the code is suppose to walk up the tree looking for a parent which is shown | 07:40 |
| bisc | tansell: yes, and that's what I'm doing. Difference from existing code is in checking not "do we have key", but "is the value empty", because this class stores empty values for all those keys | 07:42 |
| bisc | actually, the keys are not empty only for systems, because they correspond to icons | 07:42 |
| bisc | the check != 0 is needed to stop cycling if we come to universe, whose parent is itself (universe) | 07:43 |
| tansell | so what are you actually trying to do? | 07:43 |
| bisc | look. we have a planet. we want to find an icon of system that contains a planet | 07:43 |
| tansell | yes | 07:44 |
| bisc | this class is a dictionary: object_id -> icon | 07:44 |
| bisc | and we get icon only if we provide system id | 07:44 |
| tansell | yeah, all go so far | 07:45 |
| bisc | if we try self[planetid] or self[0] we get [] | 07:45 |
| tansell | Lets say we have the following | 07:45 |
| cahirwpz | tansell, hi :) | 07:45 |
| tansell | Universe A -> System A -> Planet A | 07:45 |
| bisc | yes. | 07:46 |
| bisc | current situation is that self[Universe] = [], self[System] = some_icon, self[Planet] = [] | 07:46 |
| tansell | ahh | 07:47 |
| bisc | we want to go up from planet until we get an icon or meet the universe | 07:47 |
| tansell | so the correct fix is the following, | 07:47 |
| tansell | Remove line 292? | 07:47 |
| bisc | let me think for a bit | 07:48 |
| tansell | Which will make the following | 07:48 |
| tansell | self[Universe] = [], self[System] = some_icon, self[Planet] = Nothing | 07:48 |
| tansell | cahirwpz, I was looking at your code and was a bit disheartened to see massive changes which I think I mostly disagree with | 07:48 |
| bisc | tansell: is a galaxy top level object? | 07:51 |
| cahirwpz | tansell, can you at least believe me that I'm doing those changes for better ? I know we should sit and talk about those changes, but I'm afraid we missed a lot of time to make compromises till now | 07:51 |
| tansell | cahirwpz, I believe that *you* believe that these changes are for the better | 07:51 |
| tansell | cahirwpz, but you are not working in a bubble | 07:52 |
| tansell | cahirwpz, your opinion is not the only one which matters | 07:53 |
| cahirwpz | tansell, I missed your opinion when I needed it :/ | 07:53 |
| cahirwpz | tansell, I know in the moment I'm one to blame - but can we focus on what needs to be done further ? | 07:54 |
| tansell | cahirwpz, so the big problem is that you have multiple changes we need to discuss and decide on each one | 07:54 |
| tansell | some I'm going to agree with you on, others we are going to disagree | 07:55 |
| cahirwpz | tansell, that's the way things work | 07:55 |
| tansell | cahirwpz, but your going to have to rip out the parts which we disagree on | 07:56 |
| cahirwpz | tansell, but only after discussion ;-) | 07:56 |
| tansell | so first point of argument, why are you converting everything to the sqlalchemy.orm? Your task was to port to twisted | 07:57 |
| cahirwpz | O.o | 07:57 |
| cahirwpz | sqlalchemy contains sqlalchemy.orm so I don't see any point in not using it | 07:58 |
| cahirwpz | code looks much better when orm is used | 07:58 |
| cahirwpz | its readable in first row | 07:58 |
| tansell | cahirwpz, it's a massive change to the way tpserver-py works - it's a GSoC project in itself | 07:59 |
| tansell | first row? | 07:59 |
| cahirwpz | ahh... copying language construct from Polish ;-) | 07:59 |
| cahirwpz | even if it's massive change it's almost ready - I need 2-3 days to finish it | 08:00 |
| tansell | cahirwpz, is it? It's going to take me a week or two to review this | 08:00 |
| cahirwpz | orm brings readability and flexibility to database handling - did you see how class with inheritance are mapped onto tables, and relation properties - all those things simplify code and thinking about it | 08:01 |
| tansell | cahirwpz, from what I can see, there is also quite a bit of functionality which has stopped working | 08:01 |
| cahirwpz | tansell, as I promised - server will be covered by large set of functional tests | 08:02 |
| tansell | cahirwpz, tpserver-py used to have a very particular fashion, I need to understand how it works now | 08:02 |
| cahirwpz | tansell, I understand that you were main author of it, I will spend any amount of time to help you feel as in home again | 08:03 |
| tansell | cahirwpz, so the original principle for the server was that it is a light wrapper which converts from Thousand Parsec protocol to SQL | 08:03 |
| tansell | cahirwpz, the database does the heavy lifting of storing, sorting, searching, session control, etc | 08:04 |
| cahirwpz | tansell, I consider it was main weakness of this design - it prevented moving to TP04 (and in the end I decided not to do this) | 08:05 |
| tansell | cahirwpz, I think if you had chatted with me more, I could have shown you how to convert to tp04 pretty easily | 08:05 |
| tansell | cahirwpz, as well, there are a number "up coming" features - such as object revision history - which had yet to be implemented | 08:06 |
| tansell | couple of other things; | 08:06 |
| tansell | * rulesets shouldn't modify the database | 08:06 |
| tansell | * rulesets should be able to build on each other | 08:07 |
| tansell | so lets start here | 08:07 |
| tansell | http://github.com/cahirwpz/tpserver-py/blob/master/tp/server/bases/Attributes.py | 08:07 |
| tpb | <http://ln-s.net/7C8t> (at github.com) | 08:07 |
| cahirwpz | tansell, aaaa.... don't touch it ;-) | 08:07 |
| cahirwpz | tansell, its half baked! | 08:07 |
| tansell | you have changed it so that each parameter is stored in it's own table? | 08:07 |
| cahirwpz | tansell, this module was first attempt to reimplement Attributes with greater flexibility - it failed, I'm in the middle of coming up with refined design | 08:09 |
| tansell | okay - well lets discuss tp04 and how it relates to tp03 | 08:09 |
| cahirwpz | have you seen documentation pages I generated from xml ? | 08:10 |
| tansell | what XML? | 08:10 |
| cahirwpz | protocol.xml / protocol3.xml | 08:10 |
| tansell | you mean | 08:10 |
| tansell | http://www.thousandparsec.net/tp/dev/documents/protocolxml.php | 08:10 |
| tpb | <http://ln-s.net/JXj> (at www.thousandparsec.net) | 08:10 |
| tansell | ? | 08:10 |
| cahirwpz | http://cahir.eisp.pl/doku.php?id=en:gsoc2010:doc:tp03 | 08:10 |
| tpb | <http://ln-s.net/7C94> (at cahir.eisp.pl) | 08:10 |
| cahirwpz | http://cahir.eisp.pl/doku.php?id=en:gsoc2010:doc:tp04 | 08:11 |
| tpb | <http://ln-s.net/71U8> (at cahir.eisp.pl) | 08:11 |
| cahirwpz | I studied both for a while | 08:11 |
| tansell | cahirwpz, so do you understand how orders work in tp03? | 08:11 |
| cahirwpz | The main difference is with object presentation - instead of predefined set of attributes for each object, you give flexibility to describe any object by ruleset | 08:12 |
| cahirwpz | cahirwpz, mostly yes | 08:12 |
| cahirwpz | :) | 08:12 |
| cahirwpz | tansell, mostly yes | 08:12 |
| tansell | cahirwpz, so you understand that in the tp protocol there are two parts of orders, the descriptions (kinda similar to 'class') and the actual orders (kinda similar to 'instances') | 08:13 |
| cahirwpz | yes | 08:13 |
| tansell | okay great | 08:14 |
| tansell | so the way tpserver-py worked is that you created a normal python class for each order type | 08:14 |
| cahirwpz | and some of it's attributes were mapped onto database | 08:15 |
| tansell | then on the class, you defined a set of attributes | 08:16 |
| cahirwpz | tansell, through Attribute class definition with type, default value, level of protection, and so on | 08:17 |
| tansell | yes | 08:18 |
| tansell | and the base class handled the two most complicated parts for you | 08:18 |
| tansell | getting the data in/out of the database | 08:18 |
| tansell | and converting it to/from tp packets | 08:18 |
| cahirwpz | yeah - I remember | 08:19 |
| cahirwpz | how this design helps with handling both version of protocol ? | 08:19 |
| tansell | well it doesn't help with handling *both* versions of the protocol at once - but then we don't really need to support that | 08:22 |
| cahirwpz | I talked to Epyon - he told me that tpserver-cpp supports both version | 08:22 |
| tansell | dropping tp03 support and only supporting tp04 would have been fine | 08:22 |
| tansell | cahirwpz, yes, but tpserver-cpp is a totally different beast | 08:22 |
| cahirwpz | ... do we posses rulesets which can use TP04? | 08:23 |
| tansell | cahirwpz, the process should be transparent to the rulesets | 08:23 |
| tansell | as they have never cared about how we serialised/deserialised the data | 08:24 |
| *** llnz has quit IRC | 08:24 | |
| tansell | (well atleast in tpserver-py) | 08:24 |
| *** llnz has joined #tp | 08:25 | |
| cahirwpz | one question about rulesets - you told me that they shouldn't modify database - what about advancing game by one turn ? | 08:25 |
| tansell | cahirwpz, not modify the database in the sense of needing new tables/columns/etc | 08:26 |
| tansell | so once you have setup the database initially you never have to do any changes | 08:28 |
| cahirwpz | tansell, ok... I understand... one thing you might not have spotted in current design - each game have separate set of tables - did you notice that ? | 08:29 |
| tansell | cahirwpz, yes I did notice that | 08:29 |
| cahirwpz | tansell, I decided to implement full game isolation - I'm still not sure if it was good move | 08:30 |
| cahirwpz | tansell, great :) | 08:30 |
| tansell | cahirwpz, I'm not sure it was a good move either | 08:30 |
| cahirwpz | tansell, seems that two games are not and should not be interacting with each other | 08:31 |
| cahirwpz | tansell, especially very troublesome would be implementing interaction of two games with different rulesets | 08:31 |
| tansell | cahirwpz, I can think of some cool game types which might have multiple "logic" games connected together | 08:32 |
| tansell | cahirwpz, the old tpserver-py supported two games with different rulesets running at the same time with no problem | 08:32 |
| cahirwpz | tansell, the new one will support n games with m different ruleset without any problem ;-) | 08:33 |
| tansell | s/two/any number of games/ | 08:33 |
| cahirwpz | :) | 08:34 |
| cahirwpz | so... there's one thing you might not like - I decided that different games can have a set of additional tables | 08:34 |
| tansell | yes I saw | 08:35 |
| cahirwpz | for example - minisec has additional table Ship, where in minisecplus we don't need it because we have functional Designs | 08:36 |
| tansell | cahirwpz, yes, I very much dislike this idea | 08:36 |
| tansell | cahirwpz, the idea is that once you have your DB all setup you can hand it over to a DB administrator who can optimize it, set up sharding, etc | 08:37 |
| cahirwpz | tansell, I do not modify table set as game works! | 08:37 |
| cahirwpz | tansell, when game is created I just allow to add some ruleset-specific tables | 08:38 |
| tansell | cahirwpz, but you do at game creation/removal | 08:38 |
| tansell | The flow should be | 08:38 |
| tansell | setup server, give to db admin to optimise, then create a game | 08:39 |
| tansell | creating/removing games is a common task | 08:39 |
| tansell | atleast in tpserver-py | 08:39 |
| cahirwpz | tansell, "premature optimization is the root of all evil" -- Donald Knuth ;-) | 08:40 |
| cahirwpz | tansell, I handle creating / removing games in tpserver-py-tool | 08:40 |
| tansell | cahirwpz, tpserver-py is designed with the idea that you can have multiple games all running at once, being created, deleted, etc | 08:42 |
| cahirwpz | tansell, that's great - it's exactly one of my goals :) | 08:42 |
| tansell | having new tables created/destoryed with each game means the DB admin can't do any optimisation | 08:42 |
| tansell | as no sooner has he optimised table for game X then game X ends and the table is destroyed | 08:43 |
| cahirwpz | tansell, why are you thinking of optimization now ? | 08:44 |
| cahirwpz | tansell, fast code is not needed now - we need something that works and is extensible | 08:44 |
| tansell | cahirwpz, because your design decision will mean we can *never* optimise | 08:44 |
| cahirwpz | tansell, what about db scripting ? can't admin prepare a script which will be launched before game is really started ? | 08:45 |
| cahirwpz | tansell, there will be only as much scripts as there're rulesets | 08:46 |
| cahirwpz | tansell, moreover those scripts can be partially moved to table definition in python! | 08:47 |
| tansell | cahirwpz, then we have to have hooks into the game creation process where we run a bunch of extra stuff | 08:47 |
| tansell | cahirwpz, DB admin's don't write python | 08:47 |
| cahirwpz | tansell, ahh... poor argument... we can take admin's scripts and port it to python | 08:47 |
| tansell | cahirwpz, you still don't really understand how this works do you? | 08:48 |
| tansell | cahirwpz, the way it works is that you give the db admin a database, then he plays with things on the server and everything gets magically faster | 08:49 |
| tansell | cahirwpz, he is not going to be happy with table creation/deletion all the time | 08:50 |
| cahirwpz | tansell, I assure you that I do understand ;) | 08:50 |
| cahirwpz | tansell, I just believe your concern about db performance is maybe something we should care less at now | 08:50 |
| cahirwpz | tansell, if db performance is crucial code may be redesigned | 08:50 |
| tansell | cahirwpz, your model also breaks if we have a database cluster | 08:50 |
| cahirwpz | tansell, for now we don't have working server - who cares about database performance ! | 08:51 |
| tansell | cahirwpz, but we did have a working server | 08:51 |
| tansell | so your going backwards here | 08:51 |
| cahirwpz | tansell, and you will have one - I promise | 08:51 |
| tansell | cahirwpz, you need to convince me why table creation/deletion is a *better* solution then a single table option | 08:52 |
| cahirwpz | tansell, I understand you and your concerns - but believe me - talking about performance now will not bring *any* progress | 08:52 |
| tansell | as you are loosing a bunch of possible functionality | 08:52 |
| cahirwpz | tansell, ... that's something I don't understand... which functionality ? | 08:53 |
| cahirwpz | tansell, performance != functionality | 08:53 |
| bisc | cahirwpz: imho that's kind of google philosophy -- not being careless about performance at any time :) | 08:53 |
| cahirwpz | bisc, implementing server in python instead of C++/ Erlang / Scala is against this philosophy | 08:54 |
| bisc | cahirwpz: possibly. that's another reason to keep python code smaller and allow db optimization. still, that's my personal opinion based on rather small information. | 08:55 |
| tansell | cahirwpz, just because you choose to make a sacrifice in one area doesn't mean you always choose the less performant option | 08:56 |
| tansell | bisc, did that change solve your problem? | 08:57 |
| cahirwpz | tansell, does db admin in google optimize each table by hand ? | 08:57 |
| tansell | cahirwpz, we don't really use SQL db's in google | 08:58 |
| cahirwpz | tansell, I know ;-) | 08:58 |
| cahirwpz | tansell, anyway you need to pay attention how BigTables are used... | 08:59 |
| bisc | tansell: it does. But I don't understand why to keep so strange structure for this dictionary. I mean having [] for universe and galaxies and having no key at all for planets. Why not making it clearer? | 08:59 |
| cahirwpz | tansell, ok - I stop it now, lets focus on real issue | 08:59 |
| tansell | bisc, [] means "we are not drawing the object", no key means that this is being drawn as part of another object | 09:00 |
| cahirwpz | tansell, please explain me patiently one more time - why do we need to care about db performance ? | 09:00 |
| cahirwpz | tansell, are we expecting huge volume of users like a few thousand at a moment ? | 09:01 |
| tansell | cahirwpz, no, but it's not unreasonable to expect a couple of hundred games | 09:02 |
| tansell | specially if tpserver-py makes it easy for someone to create a game on the server | 09:02 |
| bisc | tansell: understood. Is this logic introduced in this exact class (SystemLevelOverlay) or in Overlay class? I just want to leave a well-descriptive comment about it somewhere. | 09:03 |
| tansell | well it's dinner time here, be back in about an hour | 09:03 |
| tansell | bisc, in the SystemLevelOverlay | 09:03 |
| bisc | ok, thanks. | 09:04 |
| tansell | bisc, cool - it took me a while to figure out what was happening too | 09:04 |
| cahirwpz | tansell, c'ya | 09:05 |
| bisc | cahirwpz: I guess it's not easy for mithro to agree with such paradigm shift. And not only because of some rational choices and decisions. You know: you've been developing something for years keeping some concepts in mind, and then someone comes and introduces different (with certain pros and cons) concepts. | 09:09 |
| *** tpb has joined #tp | 09:14 | |
| *** ChanServ sets mode: +o tpb | 09:14 | |
| bisc | cahirwpz: you're welcome. No, I'm not attacked at all :) haven't been working on servers at all | 09:14 |
| bisc | cahirwpz: And maybe it's not about the code -- more about ideas. Maybe maintaining two types of servers (py and cpp) is sensible only if these servers are different in some ways and complement each other. | 09:15 |
| cahirwpz | bisc, I also wondered why there're two versions of TP server. The only sensible point in doing that would be keeping python server a good place for experimenting (not improving performance) and C++ version for stable and efficient solution. | 09:18 |
| bisc | cahirwpz: I can't say anything about their detailed destination, but I think that their initial ideas were justified. And maybe your changes move pyserver away from its original idea - that's why mithro isn't happy with it. | 09:20 |
| cahirwpz | bisc, but if I were concerned about efficiency and *scalability* I would never ever choose C++, only Erlang in this case | 09:20 |
| cahirwpz | bisc, good observation - thanks | 09:21 |
| bisc | cahirwpz: I see you're a fan of Erlang :) python is good for implementing complex things quickly. It gives some quick adaptability and easy extension of code. The pyserver could have ideas that benefit from these language properties. But I don't know for sure. | 09:23 |
| cahirwpz | bisc, I taught Erlang (yeah, I was lecturer!) at my university during last semester ;-) | 09:25 |
| cahirwpz | bisc, I also think that Python is great for prototyping | 09:25 |
| cahirwpz | bisc, SQLAlchemy, Django and Twisted frameworks totally kicks ass :] | 09:26 |
| bisc | cahirwpz: yeah, can't disagree with you :) | 09:28 |
| bisc | cahirwpz: are there many Erlang foss projects? | 09:29 |
| tansell | cahirwpz, I'm back now but will have to disappear shortly | 09:29 |
| tansell | cahirwpz, so let me put it this way, you are the one making a fundamental change to the way tpserver-py works - the burden of proof in showing it's a better solution is on you | 09:30 |
| cahirwpz | bisc, a lot... are you interested in something particular ? | 09:30 |
| tansell | cahirwpz, which is why even if I didn't see these performance problems you would have to give me a *good* reason to switch | 09:31 |
| cahirwpz | tansell, ok... how can we state that something is better solution ? do we have some sort of criterion (comprehensibility, extensibility, performance, maintainability) ? | 09:33 |
| bisc | cahirwpz: no, not really. Just had a though that even a better language/framework could be losing in foss popularity to less perfect, but more popular one. | 09:33 |
| tansell | cahirwpz, any of the above could be suitable | 09:33 |
| cahirwpz | tansell, ok - I'll look into non-functional software properties and try to find points against and in favor of changes I make | 09:34 |
| cahirwpz | tansell, It'd be good if we find all conflict points as soon as possible, I don't want development to be slowed because of misunderstanding etc. | 09:36 |
| tansell | cahirwpz, basically you need to come up with a list of things you have changed | 09:38 |
| tansell | cahirwpz, then we can talk through each option and come to a solution | 09:38 |
| tansell | cahirwpz, this is going to be painful because we should have done this *before* you made each change | 09:39 |
| bisc | tansell: can you have a quick look onto http://codereview.mithis.com/82001 ? | 09:39 |
| tpb | Title: Issue 82001: Popup picture removed from taskbar. - Code Review (at codereview.mithis.com) | 09:39 |
| tansell | bisc, uploaded a new version? | 09:39 |
| tansell | 82001: LGTM | 09:40 |
| bisc | tansell: hmm, not yet, doing another thing now. But relieved to have that bug solved. Will upload later. | 09:40 |
| bisc | tansell: thank you | 09:40 |
| tansell | bisc, okay - probably won't get a chance to review till tomorrow | 09:40 |
| tansell | btw - feel free to send me an email if you have any outstanding CLs I havn't looked at | 09:40 |
| tansell | I'm a bit of a scatter brain so sometimes forget about stuff :) | 09:41 |
| tansell | cahirwpz / bisc: have to head off now | 09:41 |
| bisc | tansell: bye | 09:41 |
| cahirwpz | bisc, well - looking at Erlang properties (highly concurrent and parallel, actor model, code hot-swapping, process migration) and standard library (distributed algorithms, distributed ACID database) - I think every serious server should be programmed using this language | 09:42 |
| cahirwpz | tansell, bye | 09:42 |
| bisc | cahirwpz: any other language/libraties options for a "serious server", in your opinion? | 09:43 |
| cahirwpz | bisc, with my current knowledge - none | 09:44 |
| cahirwpz | bisc, but you know... I'm limited to what I know - maybe some day I'll find something better | 09:44 |
| * llnz would now start with either django or twisted or straight python | 09:44 | |
| llnz | today | 09:45 |
| bisc | cahirwpz: okay, thanks for interesing info | 09:45 |
| cahirwpz | bisc, beware - Erlang is functional, and have some borrows from Prolog :] | 09:45 |
| bisc | cahirwpz: I'm not afraid of such functional and logical :) I'm much more afraid of starting writing big servers :) | 09:47 |
| cahirwpz | bisc, maybe you should read about history of Erlang - in fact it was designed and evolved as language + standard library in which writing distributed server is a joy ;) | 09:49 |
| bisc | cahirwpz: yeah, for me it's like reading about war -- with a hidden hope that I'll never face such things in real life practice :) | 09:53 |
| bisc | cahirwpz: thanks for interesting comments :) | 09:54 |
| *** nash has quit IRC | 10:09 | |
| * llnz wanders off | 10:41 | |
| llnz | later all | 10:41 |
| *** llnz has quit IRC | 10:41 | |
| *** bisc has quit IRC | 10:59 | |
| *** bisc has joined #tp | 11:02 | |
| *** bisc has quit IRC | 11:05 | |
| *** cahirwpz has quit IRC | 12:56 | |
| *** cahirwpz has joined #tp | 13:46 | |
| *** cahirwpz has quit IRC | 13:53 | |
| alanp | >_> | 14:15 |
| alanp | <_< | 14:15 |
| *** verhoevenv has joined #tp | 14:22 | |
| *** welterde has quit IRC | 15:56 | |
| *** welterde has joined #tp | 16:12 | |
| *** Epyon has joined #tp | 16:15 | |
| *** Epyon has left #tp | 16:15 | |
| *** null_000 has joined #tp | 16:23 | |
| alanp | null_000: PING | 17:03 |
| alanp | oops, pnig | 17:03 |
| StupidIncarnate | is there still a problem with getting planet orders? | 17:07 |
| *** epyon-kitsune has joined #tp | 17:10 | |
| null_000 | alanp: pong | 17:12 |
| alanp | null_000: with that commit #, you're able to make orders on planets? | 17:13 |
| null_000 | yes | 17:13 |
| null_000 | but not after I colonise them | 17:13 |
| alanp | sec | 17:19 |
| alanp | null_000: how long does it take you to build? | 17:20 |
| alanp | null_000: if you want to make your lead time faster, you can add components in mtsec.cpp to the scout design | 17:23 |
| alanp | example on line 712 | 17:23 |
| alanp | null_000: can you paste me message output from when you attempt a colonise? | 17:24 |
| null_000 | ok | 17:26 |
| alanp | null_000: colonisation worked for you on minisec? | 17:30 |
| null_000 | http://pastebin.com/7prmFwkL this is the output when I colonise | 17:31 |
| tpb | Title: 2010-07-06 19:30:15 < Debug > - Anonymous - 7prmFwkL - Pastebin.com (at pastebin.com) | 17:31 |
| alanp | null_000: ^ | 17:31 |
| alanp | sorry, i meant the message window of your client | 17:32 |
| null_000 | oh | 17:32 |
| alanp | do you get "You have colonised a planet" | 17:32 |
| alanp | also, did this work in minisec for you? | 17:32 |
| *** cahirwpz has joined #tp | 17:32 | |
| alanp | mtsec and minisec are a 1:1 copy for colonisation i believe | 17:32 |
| null_000 | http://pastebin.com/1i0XqDcy | 17:34 |
| tpb | Title: this is being run at /home/nul - Anonymous - 1i0XqDcy - Pastebin.com (at pastebin.com) | 17:34 |
| *** Agon has joined #tp | 17:34 | |
| null_000 | I don't remember if the colonisation worked in minisec | 17:34 |
| null_000 | here the colonisation works | 17:34 |
| *** Agon has quit IRC | 17:34 | |
| null_000 | but after I colonise a planet | 17:34 |
| alanp | right, but the order queue isn't working after | 17:34 |
| null_000 | I can't give a build order on it | 17:34 |
| alanp | does it show up as a planet owned by you? | 17:35 |
| null_000 | When I select build fleet I don't have any designs to choose from | 17:35 |
| null_000 | yes | 17:35 |
| alanp | so the orders box populates for you? | 17:35 |
| null_000 | I am the owner (but it isn't colored green) | 17:35 |
| null_000 | yes | 17:35 |
| null_000 | but after I choose build fleet I cannot choose the design.. and can not delete the build fleet order | 17:36 |
| null_000 | if I then end the turn the server crashes (if I remember correctly... I can try it now) | 17:36 |
| null_000 | oh wait... I don't even have to end the turn | 17:37 |
| null_000 | want the gdb output of the crash? | 17:37 |
| alanp | sure | 17:38 |
| null_000 | http://pastebin.com/F3gzrq8s | 17:38 |
| tpb | Title: 2010-07-06 19:30:14 < Debug > - Anonymous - F3gzrq8s - Pastebin.com (at pastebin.com) | 17:38 |
| alanp | ok, makes sense | 17:39 |
| null_000 | and after the crash the client uses most of the CPU and wants to fry it (had 108°C once) | 17:40 |
| alanp | i think you may need better cooling :P | 17:41 |
| null_000 | it's a laptop... so tell that to toshiba ^_^ | 17:41 |
| alanp | if you like, you can run the server on my box. network speeds might hurt you but building should be a bit faster | 17:42 |
| null_000 | why would building be faster? | 17:43 |
| alanp | quad core, 8g ram | 17:45 |
| alanp | not sure what the specs of your laptop are | 17:45 |
| null_000 | 2.5GHz core2 duo 4GB ram | 17:45 |
| alanp | hm not much speed improvments probably then | 17:46 |
| null_000 | ^_^ | 17:46 |
| alanp | not enough to make up for the network speeds anyways | 17:46 |
| null_000 | probably | 17:46 |
| null_000 | have to go now | 17:52 |
| null_000 | bye | 17:52 |
| *** null_000 has quit IRC | 17:52 | |
| alanp | hmmm | 17:53 |
| alanp | i see a possible fsckup | 17:53 |
| alanp | hmm no tit | 17:55 |
| StupidIncarnate | tit? lol | 18:00 |
| *** Agon has joined #tp | 18:03 | |
| alanp | hehe | 18:05 |
| *** glew has joined #tp | 18:26 | |
| *** null_000 has joined #tp | 19:09 | |
| StupidIncarnate | I'm trying to fix the visual positions of systems in a galaxy, but I'm not sure how the size of a galaxy and universe correspond to the positions of a planetary system | 19:45 |
| StupidIncarnate | the position is a lot larger than the sizes of their corresponding parents | 19:45 |
| StupidIncarnate | or maybe not, but yah, someone more informed about it? | 19:46 |
| *** llnz has joined #tp | 19:55 | |
| llnz | morning all | 19:56 |
| StupidIncarnate | morning | 19:56 |
| Agon | hello | 19:59 |
| llnz | hi Agon | 20:06 |
| StupidIncarnate | llnz, do you know about the size/position stuff for the objects | 20:07 |
| StupidIncarnate | ? | 20:07 |
| llnz | yes | 20:07 |
| StupidIncarnate | so the position of systems is how far from the point of the universe on a four quad system is it called? | 20:08 |
| StupidIncarnate | forget the term | 20:08 |
| llnz | origin | 20:09 |
| *** null_000 has quit IRC | 20:10 | |
| StupidIncarnate | I'm a bit confused abouth the size variable | 20:10 |
| StupidIncarnate | and how tha relates to the position | 20:10 |
| llnz | ok, the position gives the location of the centre of the object | 20:11 |
| llnz | and the size gives the radius/diameter (i forget which) | 20:11 |
| StupidIncarnate | alright. so on the project i'm working on, there's this for determining the x position within the constraints of the browser dimensions x = (obj.Position.x / universe.Size) * 120000 | 20:13 |
| StupidIncarnate | do you know what the 120000 number might be | 20:13 |
| StupidIncarnate | ? | 20:13 |
| StupidIncarnate | obj being a planetary system, not a galaxy | 20:15 |
| llnz | at a guess, it's used to scale things up to a reasonable size/distances | 20:15 |
| llnz | the universe is huge, but the games so far focus on a small area in the middle | 20:16 |
| StupidIncarnate | alright. And it works fine for minisec, but breaks in mtsec. Do you know why that is? | 20:16 |
| StupidIncarnate | do the dimensions change between the two sets? | 20:16 |
| llnz | how does it break? | 20:16 |
| *** Agon has quit IRC | 20:16 | |
| StupidIncarnate | One sec | 20:17 |
| StupidIncarnate | so it looks like the scale on mtsec is bigger than minisec | 20:21 |
| llnz | ok | 20:21 |
| llnz | what i suggest is finding the largest distance, and adding a bit to it, then scale everything so it fits | 20:22 |
| llnz | atleast as a start | 20:22 |
| verhoevenv | I wonder why we have a size attribute for, say, universe. How about "size of the universe is the bounding box of all contained items"? | 20:41 |
| verhoevenv | Same for star systems etc. | 20:41 |
| StupidIncarnate | hmmm, coming up with a dynamic sizer is difficult | 20:50 |
| StupidIncarnate | since the universe changes between the two rulesets | 20:50 |
| StupidIncarnate | universe size* | 20:54 |
| llnz | don't fix the value, calculate it after downloading the contents of the universe | 20:56 |
| StupidIncarnate | i'm not sure about the c++ client, but the python client and the web client allow the positions to go outside the viewport and lets the player move it around to reveal the ones the extend past the center viewport dimensions | 20:57 |
| StupidIncarnate | is there a reason why the objects can't be positioned within the constraints of the viewport so that all of them fit? | 20:57 |
| StupidIncarnate | that would solve the problem up coming up with a dynamic scale | 20:58 |
| StupidIncarnate | that's what I mean llnz, I'm not sure what value to base the scale on after I have the positions of all the objects | 20:59 |
| *** glew has quit IRC | 20:59 | |
| verhoevenv | StupidIncarnate: If you have all the objects, then you can surely calculate the bounding box? (highest/lowest object, leftmost/rightmost object) | 21:00 |
| verhoevenv | And thus determine the scale where they all fit in? | 21:01 |
| verhoevenv | Or am I missing something? | 21:01 |
| verhoevenv | (I very well might be) | 21:01 |
| StupidIncarnate | it'd have to go through all the values, and that would slow things down a bit | 21:01 |
| verhoevenv | (I don't think any ruleset uses the Z coordinate, btw?) | 21:01 |
| verhoevenv | Mmm. Still, probably the only way to accurately know the scale of things. :/ | 21:02 |
| StupidIncarnate | I suppose it could be 1.5 of the client viewport | 21:05 |
| StupidIncarnate | i guess what's confusing me is on mtsec, the universe size says it's 1000000000 | 21:07 |
| StupidIncarnate | but all the positions seem to go outside that, even if the size is the radius of the universe | 21:08 |
| StupidIncarnate | system - y:-3800000000 x:-250000000 | 21:08 |
| verhoevenv | Mmm. There never has been a real meaning enforced to the size of the universe. Which means we both have arbitrary small and arbitrary large numbers in that field. | 21:09 |
| StupidIncarnate | how can an object exist outside the universe though? | 21:10 |
| StupidIncarnate | shouldn't that be something enforced though? | 21:11 |
| *** cahirwpz has quit IRC | 21:11 | |
| verhoevenv | I'm not sure where it all came from. The current situation is not easily solved though, but you can go ahead and ask for input on the mailing list. | 21:12 |
| verhoevenv | It's illogical the way it is now anyway, so it should be adressed sometime. | 21:12 |
| verhoevenv | Now is as good as any other time. | 21:13 |
| StupidIncarnate | does anyone go to the mailing list | 21:13 |
| StupidIncarnate | ? | 21:13 |
| verhoevenv | How do you mean? | 21:13 |
| StupidIncarnate | oh i guess so | 21:13 |
| StupidIncarnate | my email must not be working | 21:14 |
| StupidIncarnate | what does that pertain to? the protocal or the server or something elne? | 21:24 |
| *** glew has joined #tp | 21:29 | |
| *** Epyon has joined #tp | 21:41 | |
| verhoevenv | StupidIncarnate: protocol or server, yeah. I'd go for changes to or at least a note in the protocol, but I'm just a lowly AI writer and I don't have to worry about the impact of those things. :) | 22:02 |
| llnz | if the universe is smaller so that it shouldn't contain the objects inside it, it's a ruleset bug | 22:05 |
| llnz | serverside | 22:05 |
| StupidIncarnate | rightyo | 22:06 |
| epyon-kitsune | llnz, have checked my commit rights? | 22:08 |
| StupidIncarnate | is this a server thing or a ruleset thing? | 22:08 |
| llnz | yes, should be working now | 22:08 |
| epyon-kitsune | great! | 22:08 |
| StupidIncarnate | http://code.google.com/p/thousandparsec/issues/detail?id=124&colspec=ID%20Type%20Severity%20Component%20Language%20Status%20Summary | 22:09 |
| epyon-kitsune | what about the new server base -- should I commit it besides the old one, or do some branchlikes? | 22:09 |
| tpb | <http://ln-s.net/7CX4> (at code.google.com) | 22:09 |
| llnz | epyon-kitsune: on the refactor branch | 22:10 |
| llnz | StupidIncarnate: probably a server, but possibly a ruleset issue | 22:11 |
| llnz | StupidIncarnate: will check it out later | 22:11 |
| epyon-kitsune | llnz: so I can remove the old main.cpp from the refactor branch and substitute it for a non-working in-progress version? | 22:13 |
| llnz | on the refactor branch, yes | 22:13 |
| epyon-kitsune | ok | 22:13 |
| epyon-kitsune | great, that gives me the flexibility I badly needed :/ | 22:13 |
| *** Epyon has left #tp | 22:19 | |
| *** jnengland77 has joined #tp | 23:48 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!