C++/Python programmers for a MUD's gamedriver wanted.

[Rythin]

Hi everyone.
We are looking for a volunteer co-programmers for a MUD's gamedriver
project. As of now, a gamedriver is divided into two separate but
tightly interconnected systems - C++ driver and Python lib.

C++ Driver is supposed to be managing memory, proccesses and
communication between them (transparent as far as net is concerned).
Python lib is to define the user's interfaces. Both of them are
designed to work in an object-oriented enviroment, with lib's classes
being driver's child-classes.

Competent level of knowledge on C++ and Python (especially embedding
Python's interpreter in apps) is required. Alternatively, we are
seeking people skilled in a use of Unix sockets and C++ system
programming.

If you are interested, email me at ry****@gmail.com (subject:
Gamedriver project) with a brief summary of your skills, C++/Python/mud
experience and things you are looking to find in this job.

You are welcome to ask any additional questions at ry****@gmail.com
(subject: Gamedriver project).
Take care,
Michael

[Paul McGuire]

"Rythin" <ry****@gmail.comwrote in message
news:11*********************@42g2000cwt.googlegrou ps.com...

Hi everyone.
We are looking for a volunteer co-programmers for a MUD's gamedriver
project. As of now, a gamedriver is divided into two separate but
tightly interconnected systems - C++ driver and Python lib.

C++ Driver is supposed to be managing memory, proccesses and
communication between them (transparent as far as net is concerned).
Python lib is to define the user's interfaces. Both of them are
designed to work in an object-oriented enviroment, with lib's classes
being driver's child-classes.

Have you considered whether the C++ Driver is even necessary? Python's
run-time engine already implements the memory and process management tasks,
and does so in compiled C code (and has been tested and retested by
hundreds, nay thousands, perhaps even millions of Python users).
Interprocess communication can be done using CORBA or Pyro add-ons.

You may do better by "letting Python be Python" instead of confining it to
limited user graphical and/or text interaction, and then
marshaling/unmarshaling commands and responses to and from the C++ layer.
Before getting too wrapped up in the C++ core/utility layer, get this (or a
prototype) running in pure Python first, measure the performance, and then
reimplement in C/Pyrex/ShedSkin/C++ for the performance-intensive bits.

-- Paul

[klibertp]

Paul McGuire wrote:

Have you considered whether the C++ Driver is even necessary? Python's
run-time engine already implements the memory and process management tasks,
and does so in compiled C code (and has been tested and retested by
hundreds, nay thousands, perhaps even millions of Python users).
Interprocess communication can be done using CORBA or Pyro add-ons.

You may do better by "letting Python be Python" instead of confining it to
limited user graphical and/or text interaction, and then
marshaling/unmarshaling commands and responses to and from the C++ layer.
Before getting too wrapped up in the C++ core/utility layer, get this (or a
prototype) running in pure Python first, measure the performance, and then
reimplement in C/Pyrex/ShedSkin/C++ for the performance-intensive bits.

-- Paul

The idea of writing C++ layer for Python lib seemed to be great, as far
as the only programmer involved in the project knows C++ a lot better,
than Python - we hoped to start as soon as possible, get the basic
services running in few weeks, learning Python 'by the way'. But in the
meantime we've realised, that even with much more people developing
this project it will surely last for years, so carefull consideration
of every little part of it is needed before writing even single line of
code. Extreme programming is nice, but we lack of proper skills -
instead we have a lot of time.

You're right - writing prototype with pure Python seems to be very good
idea. If we encounter any performance problems, reimplementing just a
part of code would be the best and easiest way to deal with them. Also,
using Python in the whole app will result with much cleaner code, the
integration between diferent modules will be done in more natural
manner.

We have to rethink whole app architecture, slowly and precisely. But
still, of course, everyone who wants to help is kindly welcomed :)

Sorry for my english if I made a mistake somewhere, and thank you for
your reply.

Piotr Klibert.