| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| *** verhoevenv has quit IRC | 00:08 | |
| *** tansell has joined #tp | 00:28 | |
| Epyon | tansell, pong? | 00:32 |
|---|---|---|
| *** StrangerDanger has quit IRC | 00:32 | |
| Epyon | glew, ping? | 00:35 |
| glew | Epyon, pong | 00:39 |
| *** mithro has joined #tp | 00:42 | |
| tansell | Epyon, ping | 00:44 |
| Epyon | tansell, I'm here | 00:44 |
| Epyon | You ping'ed me the other day. | 00:45 |
| tansell | Epyon, have you gotten the emails about your flight changes and accommodation? | 00:45 |
| epyon-kitsune | glew: do you have a project website? | 00:45 |
| epyon-kitsune | tansell: yes, quite a few of them actually :P | 00:45 |
| glew | epyon-kitsune, I have a project website, but it basically describes what I did for the week and what i plan on doing | 00:48 |
| glew | epyon-kitsune, it doesn't really document the project in high detail | 00:48 |
| Epyon | glew, actually the application itself would be the most informative | 00:49 |
| Epyon | Because I noted you're working on persistence, that... well... should undergo some changes. | 00:49 |
| Epyon | also, unless you're staying thread-safe, there'll be a problem at the end of the project. | 00:50 |
| *** StrangerDanger has joined #tp | 00:50 | |
| glew | Epyon, i do have a project proposal page on the tp wiki where the other gsoc proposals where | 00:55 |
| glew | do you need a link? | 00:55 |
| Epyon | yes :) | 00:56 |
| glew | http://www.thousandparsec.net/wiki/Google_Summer_of_Code/Proposals2010/glew | 01:03 |
| tpb | <http://ln-s.net/5aCd> (at www.thousandparsec.net) | 01:03 |
| *** nash has joined #tp | 01:14 | |
| llnz | Epyon: as i mentioned a few days ago, I will be responsible for merging glew's work into tpserver-cpp, including updating it to suit what changes occur | 01:25 |
| Epyon | llnz, I just take that as a warning to not touch anything persistence related. | 01:26 |
| Epyon | BTW, as I'm using windows to test the asio core (due to the fact that it takes ages to compile on my linux server), I came to the point that apart from avahi and syslogger, once asio | 01:28 |
| Epyon | is in the server will compile natively on windows. | 01:29 |
| Epyon | small bonus, but always... | 01:29 |
| *** Epyon is now known as epyon-okami | 01:30 | |
| llnz | cool | 01:36 |
| alanp | llnz: i'm getting segfaults on creating an order on a colonised planet | 01:37 |
| alanp | i checked, and it looks like it's using nearly the same code as minisec, and it does change the owner of the order queue | 01:37 |
| alanp | anything i'm missing? | 01:37 |
| tansell | glew, do you have a blog? | 01:38 |
| glew | tansell, yes i have a blog for weekly updates, do you want a link? | 01:40 |
| tansell | yes please | 01:40 |
| glew | http://glew2010.wordpress.com/ | 01:40 |
| tpb | Title: GSoC Weekly Update with Greg Lew (at glew2010.wordpress.com) | 01:40 |
| tansell | thanks | 01:50 |
| llnz | alanp: probably not | 01:52 |
| llnz | i'll have a look | 01:52 |
| llnz | mithro: can you look at githubs new "Organisation", and maybe swtich the thousandparsec account over | 02:03 |
| *** JohnSGalt has joined #tp | 02:22 | |
| *** StrangerDanger has quit IRC | 02:23 | |
| *** glew has quit IRC | 03:56 | |
| llnz | bbl | 04:33 |
| *** llnz has quit IRC | 04:34 | |
| *** cahirwpz has joined #tp | 05:21 | |
| tansell | cahirwpz, hello | 05:35 |
| tansell | cahirwpz, got time to chat? | 05:37 |
| cahirwpz | tansell, hi | 05:37 |
| cahirwpz | tansell, please wait for ca. 30 minutes | 05:37 |
| tansell | ca.? | 05:38 |
| *** StupidIncarnate has quit IRC | 05:42 | |
| cahirwpz | circa | 05:44 |
| tansell | cahirwpz, okay | 05:48 |
| cahirwpz | tansell, back | 06:11 |
| tansell | cahirwpz, give me 5 then we have about 2 hours to sort this all out | 06:13 |
| tansell | cahirwpz, okay | 06:26 |
| cahirwpz | tansell, lets begin :) | 06:27 |
| tansell | cahirwpz, firstly let me say the following | 06:27 |
| tansell | there are many things which are not optimal about tpserver-py, but that doesn't mean it's a good idea to spend time working on it | 06:27 |
| tansell | I highly prefer incremental changes rather then full rewrites - full rewrites tend to fail to produce good results | 06:28 |
| tansell | It's great that your excited about making tpserver-py better | 06:30 |
| tansell | Most of the things you have pointed out do need some work - but I think we disagree quite a bit about what the better solution is | 06:30 |
| tansell | Your also new to the project, you need to build up some trust/reputation before ripping everything to shreds | 06:32 |
| tansell | cahirwpz, that all good? | 06:34 |
| cahirwpz | tansell, well... basically I feel you're 100% right | 06:35 |
| cahirwpz | I have a few remarks to what I've written, but well - generally you're right | 06:36 |
| cahirwpz | * you've written | 06:36 |
| cahirwpz | I also feel that incremental changes are much better, but when design is not cared about for a longer time it's hard to build anything on top of what was written | 06:37 |
| tansell | cahirwpz, lastly - communication is as important as the code you have written. A person who writes less code but communicates with the community will be more readily accepted then a person who goes off in a hole and writes perfect code. | 06:38 |
| cahirwpz | I think if one wants to go further he/she has to have solid background | 06:38 |
| cahirwpz | tansell, completely agree about that - I know I failed at that | 06:39 |
| tansell | so lets look at the more technical stuff now | 06:40 |
| tansell | to continue the discussion we where having about configuration stuff | 06:41 |
| cahirwpz | ok | 06:42 |
| tansell | cahirwpz, you seem to have replaced a configuration file with a command line flags based system | 06:42 |
| cahirwpz | tansell, basically yes | 06:44 |
| cahirwpz | but whole mechanism is more general | 06:44 |
| cahirwpz | you can add class derived from Configurator to read configuration from another source (db, xml, ini, whatever) | 06:46 |
| tansell | It's effectively re-invention of "Google Flags" - http://code.google.com/p/google-gflags/ | 06:47 |
| tpb | Title: google-gflags - Project Hosting on Google Code (at code.google.com) | 06:47 |
| cahirwpz | tansell, possibly - I don't know this library | 06:48 |
| cahirwpz | BTW I just came up with idea of Zeroconf based Configurator | 06:48 |
| cahirwpz | however it has little sense -_- | 06:49 |
| cahirwpz | seems google-gflags is limited to getting configuration parameters from command line only | 06:50 |
| tansell | cahirwpz, so why where you compelled to rewriting this? | 06:50 |
| cahirwpz | I use builtin python library - optparse | 06:51 |
| cahirwpz | http://docs.python.org/library/optparse.html | 06:52 |
| tpb | Title: 15.5. optparse — Parser for command line options Python v2.7 documentation (at docs.python.org) | 06:52 |
| tansell | yes I see | 06:52 |
| tansell | but this system is less flexible then a Python based file | 06:52 |
| tansell | and has a huge amount more code to support it | 06:54 |
| cahirwpz | can you give me example, because I can't find one for now | 06:54 |
| tansell | import socket | 06:54 |
| tansell | # The DNS servername of this server | 06:54 |
| tansell | # The lines below will try and autodetect it. | 06:54 |
| tansell | servername = socket.gethostbyaddr(socket.gethostname())[0] | 06:54 |
| tansell | # You can also set it manually with the line below | 06:54 |
| tansell | #servername = 'mithro.dyndns.org' | 06:54 |
| tansell | serverip = socket.gethostbyaddr(servername)[-1][0] | 06:54 |
| cahirwpz | this can easily be supported | 06:55 |
| tansell | how would you do that? | 06:55 |
| cahirwpz | let me look for code sample | 06:56 |
| cahirwpz | http://github.com/cahirwpz/tpserver-py/blob/master/tp/server/db/__init__.py | 06:57 |
| tpb | <http://ln-s.net/7Dit> (at github.com) | 06:57 |
| cahirwpz | look for line 61 | 06:57 |
| tansell | looking at it now | 06:58 |
| cahirwpz | default parameter does not have to be set from string - it can be arbitrary python expression | 06:58 |
| cahirwpz | as long as it's convertible to string in this case | 06:58 |
| cahirwpz | anyway it may be dynamic | 06:58 |
| tansell | cahirwpz, but this is not about the default value | 06:59 |
| cahirwpz | ? | 06:59 |
| tansell | cahirwpz, the admin can put any python expression in their config file | 07:00 |
| cahirwpz | ah... I see | 07:00 |
| * epyon-okami retreats to his coffin for the day. | 07:00 | |
| tansell | cahirwpz, for example if the admin wanted to read that setting from /etc/hostname they could | 07:01 |
| tansell | this is extremely flexible and requires very little supporting code | 07:02 |
| tansell | less code == better | 07:03 |
| cahirwpz | ok... I see now... in my original solution I supported overriding arbitrary parameter in configuration using Python but I thrown this method out because it was not used | 07:03 |
| cahirwpz | agree | 07:03 |
| tansell | and in my experience every configuration language ends up becoming it's own language | 07:04 |
| tansell | so we should avoid this as we already have a nice user friendly language | 07:04 |
| cahirwpz | it's not meant to become language anyway - I never thought of it in such way | 07:05 |
| cahirwpz | lets look at http://github.com/cahirwpz/tpserver-py/blob/master/tpserver-py | 07:05 |
| tpb | <http://ln-s.net/7Die> (at github.com) | 07:05 |
| cahirwpz | line 23 | 07:05 |
| tansell | cahirwpz, otherwise you end up with scripts which generate your config files | 07:05 |
| cahirwpz | what about following code: | 07:05 |
| tansell | which is just as bad | 07:05 |
| cahirwpz | configurator.setParameter( DatabaseManager(), 'database', whatever_expression_or_code) | 07:06 |
| tansell | cahirwpz, I'm not sure what you are trying to get accross | 07:07 |
| cahirwpz | I understand that we're missing now the possibility to express configuration in terms of Python code | 07:09 |
| cahirwpz | I see it's reasonable but I still want to have configuration per component not global one (don't like idea of global variables) | 07:10 |
| cahirwpz | I'm trying to fix my solution to meet both worlds | 07:11 |
| cahirwpz | so maybe I should add possibility to set any configuration variable from python code and that would be exactly what we need | 07:12 |
| cahirwpz | most common parameters would be possible to configure from command line, advanced one - only from inside the code | 07:13 |
| tansell | cahirwpz, but your code adds a large amount of complexity and code which needs to be maintained for very little gain | 07:13 |
| *** StupidIncarnate has joined #tp | 07:15 | |
| cahirwpz | http://github.com/cahirwpz/tpserver-py/blob/master/tp/server/configuration.py | 07:15 |
| tpb | <http://ln-s.net/7Dio> (at github.com) | 07:15 |
| tansell | cahirwpz, you need to explain what extra value your configuration system adds | 07:15 |
| cahirwpz | core idea is in lines 9-14, 113-155 | 07:16 |
| cahirwpz | ok | 07:17 |
| cahirwpz | so IMO the most important thing is separation of concert - every configuration part is places in the module where it's actually used | 07:18 |
| cahirwpz | * concern | 07:18 |
| cahirwpz | :) | 07:19 |
| cahirwpz | if you look at CLI configuration facility - then user gets nicely formatted help + type / value safe system that fetches parameters from command line (he/she is not forced to know Python) | 07:20 |
| tansell | cahirwpz, I'm not sure these benefits are worth the extra code | 07:21 |
| tansell | cahirwpz, plus I think we could probably do the same without having to add this extra code | 07:21 |
| cahirwpz | configuration is checked before code starts working | 07:21 |
| cahirwpz | you can actually detect misconfiguration before something blows out | 07:21 |
| tansell | so I think we have two types of users | 07:23 |
| tansell | a) The simple user, will just use the default config and wants to just type ./tpserver-py and have it work | 07:24 |
| tansell | b) The advanced user, will want to customize everything, run tpserver-py on multiple servers in a cluster and some type of backend system | 07:25 |
| cahirwpz | a) user don't need CLIConfigurator nor CLIHelpFormatter, and possibly *Option classes | 07:26 |
| tansell | cahirwpz, right | 07:26 |
| tansell | I think it's reasonable to assume b) will at least have some passing familiarity with Python (or coding so can just pick up the Python syntax) | 07:27 |
| cahirwpz | I think it's safe assumption, but I able to find few use cases you omitted | 07:28 |
| cahirwpz | * I'm able | 07:29 |
| cahirwpz | what about configuration from external source (central database - SQL or LDAP) ? | 07:29 |
| tansell | are any more then niche? | 07:29 |
| tansell | cahirwpz, they have complete Python - they can write something which pulls from SQL and/or LDAP | 07:31 |
| *** bisc has joined #tp | 07:31 | |
| cahirwpz | ok... I think that I can remove lines 229-329 without triggering any issues - I still use actively this code in test client, so I'll not remove it but rather move it out of tp.server source tree | 07:32 |
| cahirwpz | but I need to think about *Option classes | 07:33 |
| cahirwpz | I think your reasons are good - we need to rework current solution | 07:34 |
| tansell | cahirwpz, okay | 07:35 |
| tansell | cahirwpz, Logging (Category: core component) | 07:37 |
| cahirwpz | tansell, yay... actually this is our first compromise, shouldn't we celebrate ? :D | 07:37 |
| tansell | cahirwpz, nope - we still have a lot to get through :) | 07:38 |
| cahirwpz | -_- | 07:38 |
| cahirwpz | :P | 07:38 |
| cahirwpz | so lets continue | 07:39 |
| tansell | cahirwpz, basically I think we should use the inbuilt logging stuff | 07:39 |
| tansell | my reason is that it's well understood for a huge number of people | 07:40 |
| tansell | again, we want to keep our code down to as little as possible | 07:41 |
| cahirwpz | there's a huge problem with builtin logging module - it does not play well with Twisted :/ | 07:41 |
| cahirwpz | but continue | 07:42 |
| tansell | cahirwpz, why/how doesn't it play well with Twisted? | 07:43 |
| cahirwpz | Twisted is asynchronous by nature, were builtin logging module is synchronous | 07:43 |
| cahirwpz | if you call logging module from Twisted it may block whole server for a while | 07:44 |
| tansell | http://docs.python.org/library/logging.html <- can't you just write a asynchronous handler | 07:44 |
| tpb | Title: 15.7. logging — Logging facility for Python Python v2.7 documentation (at docs.python.org) | 07:44 |
| cahirwpz | tansell, I was looking into it but I didn't find a way to do so - but I could possibly overlooked something | 07:46 |
| tansell | I saw a talk about it recently | 07:49 |
| cahirwpz | besides I suppose I would miss exception logging (but possibly it can be converted) and component logging (which class or set of classes have generated a message) | 07:49 |
| cahirwpz | tansell, could you give me a link or something ? | 07:50 |
| tansell | http://pypi.python.org/pypi/nonblockingloghandler/0.3 | 07:50 |
| tpb | <http://ln-s.net/7EpU> (at pypi.python.org) | 07:50 |
| tansell | http://www.youtube.com/watch?v=MN7vxKZH6EI | 07:51 |
| tpb | Title: YouTube - Python Logging: Getting the most from it - Julian Orbach (at www.youtube.com) | 07:51 |
| cahirwpz | Probably I will still need to somehow convert sqlalchemy logging with Twisted... | 07:54 |
| cahirwpz | actually there's much to investigate here | 07:54 |
| tansell | cahirwpz, it also looks like it would be trivial to create a "twisted" logging handler | 07:54 |
| tansell | from twisted.python import log | 07:55 |
| tansell | observer = log.PythonLoggingObserver(loggerName='logname') | 07:55 |
| tansell | observer.start() | 07:55 |
| cahirwpz | tansell, I considered many options some time ago and I didn't come to any reasonable conclusion - the worst of it is that I don't remember what obstacles I did find | 07:55 |
| tansell | http://www.google.com.au/search?sourceid=chrome&client=ubuntu&channel=cs&ie=UTF-8&q=using+twisted+and+logging | 07:56 |
| tpb | <http://ln-s.net/7EpZ> (at www.google.com.au) | 07:56 |
| cahirwpz | http://twistedmatrix.com/documents/current/core/howto/logging.html#auto3 | 07:57 |
| tpb | <http://ln-s.net/7Ep_> (at twistedmatrix.com) | 07:57 |
| cahirwpz | citation: One special care should be made when you use special configuration of the python logging module: some handlers (e.g. SMTP, HTTP) uses network so can block inside the reactor loop. Nothing in the bridge is done to prevent that. | 07:57 |
| cahirwpz | if we provide nonblocking handler then possibly we will get exactly what we want - I'll look into it | 07:58 |
| tansell | cahirwpz, so I think we should try really hard to use the logging module | 07:59 |
| cahirwpz | I'll try to - but first I have to investigate logging module and possibility to use nonblockingloghandler | 08:00 |
| tansell | Python’s standard logging module is used to implement informational and debug log output with SQLAlchemy. | 08:00 |
| tansell | logging.basicConfig() | 08:00 |
| tansell | logging.getLogger('sqlalchemy.engine').setLevel(logging.INFO) | 08:00 |
| tansell | logging.getLogger('sqlalchemy.orm.unitofwork').setLevel(logging.DEBUG) | 08:00 |
| cahirwpz | tansell, yeah - I know | 08:00 |
| cahirwpz | I see that converting to logging module (if possible) would bring us some benefits | 08:01 |
| tansell | cahirwpz, okay - so we are in agreement we should use the logging module? | 08:04 |
| cahirwpz | actually I don't feel confident right now to make any statement | 08:05 |
| tansell | cahirwpz, why not? | 08:05 |
| cahirwpz | I just need to browse source code and documentation of logging module and Twisted again | 08:06 |
| tansell | so I see two options | 08:06 |
| tansell | logging -> twisted.python.log | 08:07 |
| cahirwpz | I mean - in overall I agree with you | 08:07 |
| tansell | or twisted.python.log -> logging | 08:07 |
| cahirwpz | but I'm not yet sure | 08:07 |
| tansell | either way, tpserver-py should end up using the logging module and not twisted.python.log | 08:07 |
| cahirwpz | correct | 08:08 |
| tansell | okay | 08:08 |
| tansell | okay the next thing you have listed is | 08:09 |
| tansell | TP protocol transport (Category: network layer component) | 08:09 |
| cahirwpz | wait a sec | 08:09 |
| tansell | we have 50 minutes, so we better get a move on | 08:09 |
| cahirwpz | still I think we'll get back to logging at some point - I agree with your ideas, but I'm not sure they're doable - I need more time to look into the problem | 08:10 |
| cahirwpz | ok, I just wanted to make a final thought | 08:10 |
| cahirwpz | lets continue | 08:11 |
| tansell | so I think this is connected too | 08:12 |
| tansell | 6. Protocol handling (Category: network layer component) | 08:12 |
| tansell | and | 08:12 |
| tansell | 7. Client session handler (Category: client handling) | 08:12 |
| tansell | Database object backend (Category: model) | 08:12 |
| cahirwpz | somehow yes - but the do operate on different level of abstraction, and I want to keep them separated as much as possible | 08:13 |
| tansell | so I think a wholesale conversion of everything in one go is the wrong way to do it | 08:14 |
| bisc | tansell: don't want to interrupt, but can you eventually look at patches 54002, 84001, 85001and 79001 until tomorrow. | 08:14 |
| tansell | okay | 08:15 |
| tansell | probably won't get a look at it tonight | 08:15 |
| tansell | it's tempting to make such a huge change all at once as it seems like less work | 08:16 |
| tansell | but it's very hard to review, understand and leaves the server in an unknown state | 08:17 |
| cahirwpz | I agree - I don't like huge changes either | 08:20 |
| cahirwpz | but I couldn't find any logic way to split code into layers and generally highly isolated parts | 08:20 |
| cahirwpz | I felt like I couldn't change one without blowing up another one | 08:21 |
| cahirwpz | all components were tied together very strongly | 08:21 |
| tansell | well I think the database object backend code could be done totally separately of the two others | 08:21 |
| tansell | cahirwpz, and I think it might show some weeknesses of your change to the DBO | 08:22 |
| cahirwpz | tansell, what kind of concern do you have about it ? | 08:25 |
| tansell | cahirwpz, a lot | 08:25 |
| cahirwpz | name them - then I will consider them ;-) | 08:25 |
| tansell | cahirwpz, Every ORM that I have used before has been a disaster in terms of performance, configurability and actually seeing what is going wrong | 08:26 |
| tansell | I have not used SQL Alchemy's ORM before, so I can't say if it's any different | 08:27 |
| tansell | I'm also very skeptical about the advantages - I'm not really sure it makes the code all that more readable | 08:28 |
| tansell | it's a massive change to make - almost the size of a GSoC project in itself | 08:29 |
| tansell | cahirwpz, I'm not sure how you would do "versioned" objects - something I would like to see added to the server | 08:29 |
| cahirwpz | tell me about versioned object | 08:30 |
| cahirwpz | I don't know the idea behind it | 08:30 |
| tansell | Okay | 08:31 |
| tansell | do you know what "Fog of War" is? | 08:31 |
| tansell | (in game terms?) | 08:32 |
| cahirwpz | nope | 08:32 |
| tansell | okay | 08:33 |
| tansell | have you ever played starcraft or warcraft? (or another RTS?) | 08:33 |
| tansell | http://en.wikipedia.org/wiki/Fog_of_war#Simulations_and_games | 08:33 |
| tpb | <http://ln-s.net/7EqJ> (at en.wikipedia.org) | 08:34 |
| cahirwpz | warcraft II, dune II | 08:34 |
| tansell | the basic idea behind the "Fog of War" is that you can only see parts of the map where you have a Unit | 08:34 |
| cahirwpz | ahh... okay I remember now :) | 08:35 |
| tansell | cahirwpz, now if you take the concept further | 08:35 |
| tansell | you might know that an enemy base as at a certain location some time ago | 08:36 |
| tansell | but you don't know that at this moment the base has already been destoried because you have no units within range | 08:36 |
| tansell | you have "old" information | 08:37 |
| tansell | following me so far? | 08:37 |
| cahirwpz | yes :) | 08:38 |
| tansell | great | 08:38 |
| tansell | so the way this was/is going to work on the server is as follows | 08:38 |
| cahirwpz | could you possibly write down the whole idea and put somewhere - I think it might be good idea if you think about it in depth - many issues may appear | 08:38 |
| cahirwpz | * put it | 08:38 |
| tansell | each time an object changes, a new entry is stored in the database (this happens at most once per turn) | 08:39 |
| tansell | each player has a "pointer" to the current version of the object they know about | 08:39 |
| tansell | so for example in the above the player who owns the base will have a pointer to the latest version | 08:40 |
| tansell | while the other player will have a pointer to an older version | 08:40 |
| tansell | when the other player moves a unit within range, he gets a pointer to the latest version | 08:41 |
| tansell | make sense? | 08:41 |
| cahirwpz | okay, so each player sees a universe with many objects, and each object is from some particular turn that passed | 08:41 |
| tansell | yes | 08:41 |
| tansell | a slightly more advanced version adds "masks" to the pointer | 08:42 |
| tansell | these masks effectively tell you which attributes you see at that version | 08:42 |
| cahirwpz | yes, but I want to get the abstract idea - I'm used to think declaratively not imperatively - I'm not interested at this point how should it be done, but what we want to obtain | 08:43 |
| tansell | so for example, you may only know the population of a planet when you have a ship in orbit | 08:43 |
| tansell | but you know a planets mineral makeup from a distance | 08:44 |
| cahirwpz | I played Master of Orion 2 a lot | 08:44 |
| tansell | so these two attributes could have different effective ages | 08:44 |
| cahirwpz | I more or less can imagine what you want to have | 08:44 |
| tansell | you may not know the population at the current time - but do know the planets mineral makeup | 08:45 |
| tansell | or you might have old data for the population of the planet | 08:45 |
| cahirwpz | seems reasonable | 08:45 |
| cahirwpz | should be that controlled by ruleset ? | 08:45 |
| cahirwpz | I mean a set of visible attributes | 08:45 |
| tansell | yes | 08:46 |
| cahirwpz | okay... please write down the whole idea somewhere I'll think about it | 08:46 |
| tansell | I don't really have much time to write this down, otherwise it would have already been done | 08:47 |
| tansell | cahirwpz, I worry that using an ORM is going to make doing something like this impossible | 08:48 |
| tansell | because it's too "smart" | 08:48 |
| tansell | this is actually pretty simple to do in SQL | 08:48 |
| tansell | s/ORM/a generic ORM/ | 08:49 |
| cahirwpz | that on the other hand is something I can hardly believe ;-) | 08:49 |
| cahirwpz | but I might be wrong - I'll think about it | 08:49 |
| tansell | cahirwpz, what do you mean? | 08:50 |
| cahirwpz | I mean I'll think how much effort I'd need to add versioning to the current solution | 08:51 |
| tansell | It would take me about a week to get a working/tested solution added to the current structure - but I have not had a week to do such a change | 08:52 |
| tansell | and more important things need working on | 08:52 |
| tansell | anyway going back to the ORM/Packet stuff | 08:53 |
| tansell | I also think there is some utility to have everything to do with one thing in one class | 08:53 |
| tansell | IE having the packet serialising/unserialising in the Board/Object/etc classes | 08:53 |
| tansell | cahirwpz, btw we are almost out of time | 08:54 |
| cahirwpz | that's a pity... the discussion started to be very interesting | 08:54 |
| cahirwpz | okay so about serialising / deserialising - I think such solution ties protocol and DB objs very strongly | 08:56 |
| cahirwpz | IMHO DB objects should influence the design of protocol, not vice versa | 08:57 |
| tansell | you have it the wrong way around | 08:57 |
| tansell | The protocol comes first - and is influenced by what type of games we want to support | 08:58 |
| cahirwpz | we want to have a model of the universe, ruleset that operate on universe, and a protocol which is a medium of transporting view of universe to a client | 08:58 |
| cahirwpz | okay... let me ask this question: | 08:58 |
| cahirwpz | what is more important - ruleset and model, or protocol ? | 08:58 |
| cahirwpz | what makes the game ? | 08:58 |
| tansell | the ruleset is what makes the game - but the protocol is what allows us to have multiple clients/servers all work together | 08:59 |
| tansell | if you where just working on a single game | 08:59 |
| tansell | you wouldn't care about the protocol at all | 08:59 |
| tansell | but as this is a generic framework for building a given type of game the protocol is very important | 09:00 |
| tansell | the protocol dictates what type of games can be built, how they have to be structured, etc | 09:00 |
| cahirwpz | actually not | 09:00 |
| cahirwpz | ruleset and model limits you what kind of game you can make | 09:01 |
| cahirwpz | the more flexible ruleset is the more games you can produce | 09:01 |
| cahirwpz | protocol is only a medium between client and server | 09:01 |
| cahirwpz | a way to see universe and do some actions in it | 09:01 |
| tansell | the protocol restricts what can be in the universe and what type of actions can be performed | 09:02 |
| tansell | IE you can't make a real time strategy with the current protocol | 09:02 |
| tansell | or a FPS | 09:02 |
| *** tansell-laptop has joined #tp | 09:04 | |
| cahirwpz | well - we do want to make turn based strategy | 09:04 |
| cahirwpz | and we should think in terms of such games | 09:04 |
| cahirwpz | even for such type of games model and ruleset should be as flexible as protocol | 09:05 |
| cahirwpz | ouch | 09:05 |
| cahirwpz | as flexible as possible | 09:05 |
| cahirwpz | protocol shouldn't restrict what is possible to do in the universe | 09:05 |
| cahirwpz | putting restrictions on model and ruleset actually kills the innovative thinking about what kind of game it's possible to make | 09:07 |
| cahirwpz | tansell, am I wrong ? | 09:08 |
| tansell-laptop | so the protocol is pretty open | 09:09 |
| cahirwpz | but unfortunately type unsafe | 09:10 |
| tansell-laptop | what do you mean? | 09:10 |
| cahirwpz | at least part of parameters stuff | 09:10 |
| cahirwpz | you just use bare database row id in communication with a client | 09:11 |
| cahirwpz | I believe there're cases when you send Resource.id or Design.id and you don't make difference - whole interpretation is on server side | 09:12 |
| cahirwpz | that harness safety - you have to add additional code to check if someone don't want to misuse orders | 09:12 |
| *** epyon-okami has quit IRC | 09:13 | |
| cahirwpz | tansell, I personally think that TP game should abstract over protocol as much as possible and focus on playability == rulesets and model | 09:14 |
| cahirwpz | protocol should be easily replaceable if it is not sufficient to transfer all needed information about the universe | 09:16 |
| tansell-laptop | cahirwpz, okay - I buy that having a good abstraction between the two is good | 09:16 |
| cahirwpz | that's great - I'm very happy to hear that | 09:17 |
| tansell-laptop | but adding abstraction has a cost | 09:17 |
| cahirwpz | of course the protocol is something that I don't want to mess with now - maybe next GSoC | 09:17 |
| tansell-laptop | so you need to balance the cost of the abstraction with the benefit | 09:18 |
| cahirwpz | tansell, I think abstraction cost is always acceptable until we really need performance - and that should happen for some time | 09:19 |
| tansell-laptop | the cost is not just performance, but understanding what is actually going on | 09:20 |
| tansell-laptop | and simplicity | 09:20 |
| cahirwpz | it's about overall goodness of abstraction | 09:20 |
| tansell-laptop | adding too much abstraction makes things hard to reason about | 09:21 |
| cahirwpz | I think that good abstraction frees you of thinking about details and let you express your thoughts easier | 09:21 |
| cahirwpz | it hides details you don't want to care when you try to come up with solution | 09:22 |
| *** StupidIncarnate has quit IRC | 09:22 | |
| cahirwpz | so for example I believe that ruleset should know as little about database persistence as possible | 09:22 |
| cahirwpz | you want to operate on model - not on database | 09:22 |
| cahirwpz | you need to express how the universe changes not how table is modified - that's obvious to me | 09:23 |
| cahirwpz | this is a principle of MVC design pattern (I think so) | 09:24 |
| tansell-laptop | so I agree that ruleset shouldn't really care about the database | 09:27 |
| cahirwpz | that's what I wanted to obtain using ORM - but I general I find your concerns about ORM (in general) as justified | 09:29 |
| cahirwpz | * in general | 09:29 |
| tansell-laptop | okay | 09:30 |
| tansell-laptop | the original code is effectively a ORM | 09:31 |
| tansell-laptop | but it was very specific to the one use case | 09:31 |
| tansell-laptop | which means you can cut a lot of corners | 09:32 |
| cahirwpz | I don't want to offend you in any way - but I think it was quite messy and in fact was another attempt to reinvent the wheel (as probably my CLIConfigurator and google gflags) | 09:34 |
| cahirwpz | I don't know if SQLAlchemy ORM is good for us | 09:34 |
| tansell-laptop | sometimes specific is better then generic | 09:34 |
| cahirwpz | It's just a guess... and maybe an experiment | 09:35 |
| tansell-laptop | cahirwpz, the code is quite old, but it has worked pretty well | 09:35 |
| cahirwpz | tansell, it was not covered by tests | 09:35 |
| cahirwpz | even if we take somehow restricted ORM we get a lot of benefits | 09:36 |
| tansell-laptop | cahirwpz, it was also not originally written to be more then an experiment | 09:36 |
| cahirwpz | they do work on it - not us | 09:36 |
| cahirwpz | we just get (possibly) optimized and tested solution (with more than one database) | 09:37 |
| cahirwpz | the drawback is that we need to learn it and possibly overcome restrictions and quirks | 09:38 |
| tansell-laptop | which is more work then you probably realised | 09:38 |
| cahirwpz | what do you exactly mean ? | 09:38 |
| tansell-laptop | --> possibly overcome restrictions and quirks | 09:39 |
| tansell-laptop | those two takes more then then you realise | 09:40 |
| cahirwpz | http://www.sqlalchemy.org/docs/05/mappers.html#extending-mapper ;-) | 09:40 |
| tpb | <http://ln-s.net/4pa8> (at www.sqlalchemy.org) | 09:40 |
| cahirwpz | the same risk is with Twisted and any other big framework | 09:41 |
| tansell-laptop | yes | 09:41 |
| tansell-laptop | so we should be doing a bunch of big changes all at once | 09:41 |
| tansell-laptop | s/should/shouldn't/ | 09:41 |
| cahirwpz | well - don't forget about test client which should help a lot | 09:41 |
| tansell-laptop | IE twisted change should be done seperately from the ORM conversion | 09:41 |
| tansell-laptop | I agree that tests are a good thing to have | 09:43 |
| *** bisc has quit IRC | 09:43 | |
| *** nash has quit IRC | 09:43 | |
| cahirwpz | tansell-laptop, that would be in the ideal world - I also wanted that (fine-grained changes), but unfortunately found it impossible to do :/ | 09:44 |
| tansell-laptop | cahirwpz, I still see no reason that the twisted change couldn't be done separate from the ORM | 09:44 |
| tansell-laptop | I have to go very shortly | 09:45 |
| tansell-laptop | just finished my dinner | 09:46 |
| tansell-laptop | have to go home | 09:46 |
| cahirwpz | so maybe we should talk about the rest at Wednesday - I have a busy morning tomorrow :( | 09:46 |
| cahirwpz | need to go to a doctor | 09:46 |
| *** bisc has joined #tp | 09:47 | |
| tansell-laptop | so the survey begins tomorrow | 09:47 |
| *** bisc has joined #tp | 09:47 | |
| tansell-laptop | so I would like to get this sorted ASAP | 09:48 |
| tansell-laptop | cahirwpz, so I think we agree on two things | 09:48 |
| tansell-laptop | a) your going to fix tpserver-py to use logging module (and connect it up to twisted) | 09:48 |
| tansell-laptop | b) go back to the previous config system | 09:50 |
| tansell-laptop | right? | 09:50 |
| tansell-laptop | got to run now | 09:52 |
| tansell-laptop | see ya | 09:52 |
| cahirwpz | a) ok... I agree - however I feel a bit forced to make that agreement because I still need some time to investigate if it' possible | 09:53 |
| cahirwpz | b) I don't agree to revert all changes, but agree to remove CLIConfigurator and stuff that is related to it | 09:54 |
| *** mithro has quit IRC | 09:55 | |
| cahirwpz | c'ya | 09:55 |
| *** verhoevenv has joined #tp | 10:10 | |
| *** cahirwpz has quit IRC | 10:25 | |
| *** mithro has joined #tp | 10:25 | |
| *** cahirwpz has joined #tp | 12:00 | |
| *** bisc has quit IRC | 14:59 | |
| *** Epyon has joined #tp | 15:26 | |
| *** peres has joined #tp | 15:59 | |
| * epyon-kitsune would kill for air conditioning now | 17:01 | |
| *** peres has quit IRC | 17:15 | |
| *** Erroneous has joined #tp | 17:16 | |
| *** glew has joined #tp | 17:45 | |
| *** null_000 has joined #tp | 17:46 | |
| null_000 | hi all | 17:48 |
| null_000 | alanp: ping | 17:52 |
| *** cahirwpz has quit IRC | 18:06 | |
| *** Erroneous has quit IRC | 18:11 | |
| *** null_0001 has joined #tp | 18:34 | |
| *** null_000 has quit IRC | 18:34 | |
| Epyon | Hmm, there's no way to get through by atomic steps, the whole network code including connection classes will have to be rewritten ground up | 18:41 |
| *** StupidIncarnate has joined #tp | 18:43 | |
| * Epyon waits for llnz | 18:44 | |
| *** Epyon is now known as epyon-okami | 18:44 | |
| *** null_0001 has quit IRC | 18:54 | |
| *** cahirwpz has joined #tp | 19:25 | |
| *** cahirwpz has quit IRC | 19:46 | |
| *** JohnSGalt has quit IRC | 20:01 | |
| *** StrangerDanger has joined #tp | 20:08 | |
| *** llnz has joined #tp | 20:24 | |
| *** StrangerDanger has quit IRC | 20:29 | |
| *** StupidIncarnate has quit IRC | 20:38 | |
| llnz | morning all | 20:44 |
| alanp | hey | 20:57 |
| alanp | any luck with that planet order queue issue we're having? | 20:57 |
| alanp | i'm going to take another look tonight | 20:57 |
| llnz | sorry, didn't get a chance, busy with family | 20:57 |
| alanp | no worries | 21:00 |
| *** StrangerDanger has joined #tp | 21:11 | |
| *** mithro has quit IRC | 21:59 | |
| llnz | afk | 22:00 |
| epyon-kitsune | llnz: ping me when you're near the keyboard again | 22:00 |
| *** mithro has joined #tp | 22:17 | |
| *** mithro has quit IRC | 22:27 | |
| *** epyon-okami has quit IRC | 22:39 | |
| *** epyon-okami has joined #tp | 23:19 | |
| *** epyon-okami is now known as Epyon | 23:19 | |
| * llnz is back | 23:50 | |
| llnz | epyon-kitsune, Epyon: ping | 23:50 |
| epyon-kitsune | llnz: I'm getting into a much bigger mess each hour -_- | 23:54 |
| epyon-kitsune | basically there are three things that are done simultanously now | 23:54 |
| epyon-kitsune | 1) small steps to the server itself -- on the git branch | 23:54 |
| epyon-kitsune | 2) a new core being written completely seperated, and rewritten from time to time | 23:55 |
| epyon-kitsune | 3) a windows based not working compilation of tpserver-cpp where I do tests trying to find the most step-by-step asio integration. | 23:55 |
| epyon-kitsune | these three things should get together, but I see no way in achieveing that in the next days. | 23:56 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!