23 Mar 07:07
15 Mar 02:50
6 Dec 03:00
6 Jul 20:46
Re: Changes to Makefiles to add SQLite Persistence
Gregory Lew <gregory.lew <at> mail.mcgill.ca>
2010-07-06 18:46:08 GMT
2010-07-06 18:46:08 GMT
________________________________________ From: tp-devel-bounces <at> thousandparsec.net [tp-devel-bounces <at> thousandparsec.net] On Behalf Of Gregory Lew [gregory.lew <at> mail.mcgill.ca] Sent: Tuesday, July 06, 2010 2:44 PM To: tp-devel <at> thousandparsec.net Subject: [tp-devel] Changes to Makefiles to add SQLite Persistence Hi Everyone, I've been working on a sqlite persistence module for GSOC and I was wondering if someone could help me. I know I need to add things to the makefiles for it to be compiled with the tpserver-cpp, but I'm not sure exactly what needs to be added or changed. Thanks, Greg _______________________________________________ tp-devel mailing list tp-devel <at> thousandparsec.net http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
6 Jul 20:44
Changes to Makefiles to add SQLite Persistence
Gregory Lew <gregory.lew <at> mail.mcgill.ca>
2010-07-06 18:44:28 GMT
2010-07-06 18:44:28 GMT
Hi Everyone, I've been working on a sqlite persistence module for GSOC and I was wondering if someone could help me. I know I need to add things to the makefiles for it to be compiled with the tpserver-cpp, but I'm not sure exactly what needs to be added or changed. Thanks, Greg
16 Jun 13:26
"Object isn't new enough" error (issue 97)
Damjan Košir <damjan.kosir <at> gmail.com>
2010-06-16 11:26:45 GMT
2010-06-16 11:26:45 GMT
Hi everybody!
It looks like the tpserver-cpp doesn't update the modification times correctly for objects when they get new orders. So it's possible that the order has newer modification time than the object with this order. I'm no protocol specialist but I think this shouldn't happen.
The client throws an "object isn't new enough" error when this happens. Steps how to reproduce it are available here http://code.google.com/p/thousandparsec/issues/detail?id=97 .
By clearing cache I made sure the corrupt data really gets send by the server. I also found it interesting that the server sends different modified times to different players for the same object.
Since the stable branch of the python client isn't affected I tried to find out which commit caused the problem and it is this one http://github.com/thousandparsec/tpclient-pywx/commit/d5535b764ae462523987d647ad1635c81f5dad61 . It is a change of libtpclient-py version the client uses. The change in the library was this http://github.com/thousandparsec/libtpclient-py/commit/a68e90616cb9795d17f7c1332de1e001f73d44b6#diff-0 .
Currently I am using a dirty workaround in libtpclient that doesn't use cache and corrects the modified times if needed. This isn't a solution, just a temporary workaround with unknown side effects.
As my knowledge of tpserver-cpp and C++ is very very limited I can not fix this myself. This bug has been blocking my GSoC AI development for some time now so any help would really be appreciated.
Damjan 'Null' Košir
It looks like the tpserver-cpp doesn't update the modification times correctly for objects when they get new orders. So it's possible that the order has newer modification time than the object with this order. I'm no protocol specialist but I think this shouldn't happen.
The client throws an "object isn't new enough" error when this happens. Steps how to reproduce it are available here http://code.google.com/p/thousandparsec/issues/detail?id=97 .
By clearing cache I made sure the corrupt data really gets send by the server. I also found it interesting that the server sends different modified times to different players for the same object.
Since the stable branch of the python client isn't affected I tried to find out which commit caused the problem and it is this one http://github.com/thousandparsec/tpclient-pywx/commit/d5535b764ae462523987d647ad1635c81f5dad61 . It is a change of libtpclient-py version the client uses. The change in the library was this http://github.com/thousandparsec/libtpclient-py/commit/a68e90616cb9795d17f7c1332de1e001f73d44b6#diff-0 .
Currently I am using a dirty workaround in libtpclient that doesn't use cache and corrects the modified times if needed. This isn't a solution, just a temporary workaround with unknown side effects.
As my knowledge of tpserver-cpp and C++ is very very limited I can not fix this myself. This bug has been blocking my GSoC AI development for some time now so any help would really be appreciated.
Damjan 'Null' Košir
14 Jun 10:10
Error with python cache use
Joey <tradedaemon <at> gmail.com>
2010-06-14 08:10:55 GMT
2010-06-14 08:10:55 GMT
Hi, I'm working on tpclient-pyweb. When I send a command to the server using cache.apply, I get the following message. I'm not completely familiar with how the threading works, but is this basically saying that I've created a sub thread and it's conflicting with the current one?
Traceback (most recent call last):
File "./backend/exception_middleware.py", line 20, in __call__
appiter = self.app(environ, start_response)
File "/usr/lib/pymodules/python2.6/beaker/middleware.py", line 152, in __call__
return self.wrap_app(environ, session_start_response)
File "./backend/application.py", line 322, in application
return callback(environ, start_response)
File "./backend/application.py", line 167, in send_orders
order_id = middleman.Orders(cache).sendOrder(cache, conn, int(postdata['id'][0]), int(postdata['type'][0]), args)
File "./backend/middleman.py", line 377, in sendOrder
apply(conn, evt, cache)
File "libtpclient-py/tp/client/cache.py", line 870, in apply
cache.commit(evt)
File "<string>", line 1, in <lambda>
File "libtpclient-py/tp/client/threadcheck.py", line 6, in thread_check_callable
assert self._thread is threading.currentThread(), "%s can only be called by %s not %s" % (func, self._thread, threading.currentThread())
AssertionError: <function commit at 0x21fe5064> can only be called by <_DummyThread(Dummy-3, started daemon -1250780304)> not <_DummyThread(Dummy-2, started daemon -1242387600)>
28 May 18:03
Parsek and KDE dependency
marcel.hauf <marcel.hauf <at> googlemail.com>
2010-05-28 16:03:03 GMT
2010-05-28 16:03:03 GMT
Hello thousand parsec developers, I was thinking about Parseks KDE dependency and how much it binds the users to KDE and its huge base libs. While looking for a way to implement KWallet support. I wondered why Parsek has KDE as a dependency. If I take a look at how much KDE code is used in Parsek, it isn't much and I am wondering if it is necessary to keep Parsek as an KDE app or move away from that dependency. That are just some thoughts. I told llnz about my thoughts on IRC and he suggest to discuss this on the mailing list and also get some input from JLP. He had also some points. First, "being in KDE means that if we can get parsek into kdegames, a lot more people will have a client, and might play". Second, "if we can get away with less or no direct KDE dependencies than that might also work" About the second point, it is possible to get some native KDE features without KDE as dependency, mainly through DBus, since KDE 4 exposes a lot of features like KNotify and KWallet. Moving to pure Qt means also to get Parsek on Windows, Mac and smart phones. I know most KDE apps work under Windows more or less but it also requires the base libs. I know it is a huge change in the target audience that is the reason I want to discuss this on the mailing-list, also with the creator of Parsek. Please, provide constructive feedback. By the way I am a KDE 4 user so this is not about hating KDE ;) . ~ Marcel (Agon) Hauf
20 May 19:33
Protocol specification error
Damjan Košir <damjan.kosir <at> gmail.com>
2010-05-20 17:33:35 GMT
2010-05-20 17:33:35 GMT
While looking at protocol specifications for design packet and client code I've found something interesting. In tp.netlib.objects.Design design ID and last modified time are specified as SInt types, but in the protocol specifications they are specified as UInt. Also in the protocol specification it says "If adding a design send the ID as -1". You can not send a UInt with a value of -1. The protocol specifications should be updated to fit the implementation (and perhaps save someone from a headache in the future ^_^) Damjan 'Null' Košir
20 May 19:33
Protocol specification error
Damjan Košir <damjan.kosir <at> gmail.com>
2010-05-20 17:33:17 GMT
2010-05-20 17:33:17 GMT
While looking at protocol specifications for design packet and client code I've found something interesting. In tp.netlib.objects.Design design ID and last modified time are specified as SInt types, but in the protocol specifications they are specified as UInt. Also in the protocol specification it says "If adding a design send the ID as -1". You can not send a UInt with a value of -1. The protocol specifications should be updated to fit the implementation (and perhaps save someone from a headache in the future ^_^) Damjan 'Null' Košir
16 May 12:22
libtpclient-py problems and a patch
Damjan Košir <damjan.kosir <at> gmail.com>
2010-05-16 10:22:34 GMT
2010-05-16 10:22:34 GMT
Hi! Libtpclient-py has an unused import of something that is not included with it. It is ok when used in tpclient-pywx but not anywhere else. I've attached a patch for this. Libtpclient-py also imports objectutils from extra. This is also not included. You can make it work by copying objectutils.py from extra from tpclient-pywx, but this is only a workaround. Objectutils.py must become a part of libtpclient-py or it should not be used. Damjan 'Null' Košir
diff --git a/tp/client/threads.py b/tp/client/threads.py index c173a30..dfed9f5 100644 --- a/tp/client/threads.py +++ b/tp/client/threads.py @@ -13,7 +13,6 @@ from version import version from tp.netlib.objects import parameters from tp.netlib import objects -from requirements import graphicsdir from extra import objectutils
RSS Feed