Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: [RFC] Embedding Python
Home

[Freeciv-Dev] Re: [RFC] Embedding Python

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Lino Mastrodomenico <mastro@xxxxxxxxxx>
Cc: Freeciv-dev ML <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Embedding Python
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 5 Oct 2001 12:57:46 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Tue, Oct 02, 2001 at 10:58:18AM +0200, Lino Mastrodomenico wrote:
> Hi all.
> 
> I have attached 2 work-in-progress patches for embedding python in the 
> server, if you are impatient please see this screenshot:
> 
>   http://www.mastrodomenico.f2s.com/freeciv/temp/python1.png

Finally had someone merged two very nice projects: freeciv and python.

> The first patch (embed_python.diff) simply embed the python, without doing 
> anything else.
> The second (python_callbacks.diff) creates a new server variable, "script", 
> that specify a server script to load (please see data/script/default.py for 
> an example).
> 
> This script can be used for writing:
>   * dynamic scenarios (it would be nice to offer all the capabilities of civ2 
>     script language (for a detailed description see:
>     <http://apolyton.net/forums/showthread.php?s=&threadid=17520>), so we can
>     eventually write an utility for automatic importing civ2 scenarios);
>   * user AIs;
>   * user agents;
>   * server gui (?);
>   * cheats...
> (well... at least in the future: for now it can only spam messages using the 
> wall function)
> 
> If we embed python in the client, it should be possible to allow AIs and 
> agent scripts to run both server-side and client-side, by using a construct 
> like:
> 
>   try:
>       from civserver import game
>       wow_now_i_can_cheat = 1
>   except ImportError:
>       from civclient import game
>       wow_now_i_can_cheat = 0
> 
> 
> After applying both patches you should run:
> 
>   automake && autoheader && autoconf && ./configure --with-python
> 
> You need both python and python-devel packages.
> Technically it should work with python 1.5.2+ (tested with 1.5.2, 2.0 and 
> 2.2a2), but if we want distribute a _precompiled_ executable we must use a 
> version with a GPL-compatible license (2.0.1, 2.1.1 or 2.2).
> 
> 
> Technical details:
> 
>   * all the interactions between the server and the script take place through 
>     the "civserver.game" python object (from the python side) and through the 
>     script.c file (from the c side);
> 
>   * the game object contains (for now...):
>       - data attributes:
>           * is_new_game
>           * year
>           * turn
>         (they came from "struct civ_game game"; to add new attributes simply  
>         copy them from game.h to data/script/civserver.i and rerun swig)
> 
>       - methods:
>           * wall(string)
>             (it works like the server wall command)
> 
>       - callback handlers lists (use X.append(my_func) to add a new callback  
>         and X.remove(my_func) to remove it):
>           * begin_turn
>           * start_game
> 
>   * I have used swig 1.3a5; the generated files are included in the patch, so 
>     you need swig only if you modify civserver.i (more than half of the
>     second patch size is automatically generated);
> 

>   * I think is a bit stupid inserting a copyright like "(C) 1996 - A
>     Kjeldberg, L Gregersen, P Unold" in a code written in 2001

Ack.

>     , so I have
>     used "(C) 2001 - Lino Mastrodomenico" in the new files that I have
>     created. If this is a problem 

No problem.

>   * The script.c interface is high-level and not python-specific, so we can
>     later embed other languages (guile, perl, tcl, ruby...).
> 
> 
> And now some very nice ascii art:
> 
> *  ================C================   ============Python=============
> *   ___________    ________________     ______________     __________
> *  /           \  /                \   /              \   /          \
> *  |           |--|    script.c    |---|              |   |   user   |
> *  |           |  \________________/   | civserver.py |---|  script  |
> *  |  Freeciv  |    |   _____|_____    |              |   |          |
> *  |           |    |  /           \   \______________/   | (AI,     |
> *  |  server   |    |  | libpython |          |           | dynamic  |
> *  |           |    |  \___________/          |           | scenario |
> *  |  classic  |   _|________|_____     ______|________   | ...)     |
> *  |           |  /                \   /               \  \__________/
> *  |           |__| swig_wrapper.c |___| _civserver.py |
> *  |           |  |   (by swig)    |   |   (by swig)   |
> *  \___________/  \________________/   \_______________/
> 
> 
> I hope this isn't too confusing ;-) (however the code should be simple to 
> understand).
> 
> 
> Of course these patches are not ready for cvs inclusion: this it's a 
> proof-of-concept/work-in-progress and I now need some feedback.
> 
> Comments? Suggestions? Flames? ;-)

Very nice. My main problem is that it runs at the server which is IMHO
only needed for dynamic scenarios. Running user AIs or user agents
in/at the server should be done in a seperate process at the
server. This gives the same interface for the ai/agents and disallow
cheating.

Another point is that the number of things which are accessible from
the python side is just to small ;)

What is your plan? What are your next steps?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  reality.sys corrupt. Reboot Universe? (y,n,q)


[Prev in Thread] Current Thread [Next in Thread]