Mudlet - Forum

I replied to a thread a few months back where I showed a mudlet mod with python support that I had just made. I have decided to create a topic on it since it has grown from mudlet with just a barebone interpreter installed to currently supporting most of the features that can be found in the lua api. I owe much thanks to KrimMalak for the help with adding in a lot of the python functions.

The source can be cloned from:
git://github.com/Aico/mudlet.git

supported:

• Lua api equivalent python functions.

• full mapper support in python.

• Python coexists with Lua so you can use both.

not supported:

• Lua and Python do not share variable space.

Is your repo in sync with the latest mudlet release in the main sf.net repository? When the repo is in sync and if it compiles on windows and macs (please update mac_src.pro) I'll try to merge the python support. Which GPL compliant Python package do you want to ship with with windows build?

I will work on syncing to the sf repo. The last time I merged from sf was in July so I will need to work with half a year of changes. Luckily most of the additions are confined to the Python specific classes so the process shouldn't be too much of a problem. I'll also test it out in Windows, the last time I tried that a few months ago, the way to compile for windows wasn't quite worked out yet, but I see now that some have claimed success. Theoretically, since the only additional requirement for an ubuntu compile is python-dev, so I'll expect I'll be able to follow the Windows compiling instructions others have worked out. As for mac, I'll attempt to update the mac_src.pro, but I don't have an easily accessible mac so I'll have to see if someone could help me with that.

Sounds like some great work, and good progress. I'd love to see completion of python support for Mudlet. I'd surely make use of it and let you know of bugs.

Merge? Wouldn't it slow us down trying to run two interpreters simultaneously? Also, make variable interpretation more complicated?

tsuujin wrote:Merge? Wouldn't it slow us down trying to run two interpreters simultaneously? Also, make variable interpretation more complicated?

The Python interpreter can be turned off in Settings, then it will be exactly the same as the current mudlet. As for the second point, since the the two interpreters do not share variables, there really isn't any ambiguity, if you're writing a Lua script, you can't access Python variables directly even if you wanted to.

I love python. This rocks. Do you have a dynamic way of keeping in sync with the lua interpreter function calls?

chris wrote:I love python. This rocks. Do you have a dynamic way of keeping in sync with the lua interpreter function calls?

Currently no.

One way could perhaps just having a python.callLua(...) function which will reroute to the called function. Then all you need to do is reinterpret the output (tables->dict and everything else is automatic typing more or less).

tsuujin wrote:Merge? Wouldn't it slow us down trying to run two interpreters simultaneously? Also, make variable interpretation more complicated?

Of course we need to make sure that there is no significant performance loss. I haven't looked at the python code for several months so there may be issues that have to be changed.

Generally speaking having 2 scripting languages has little impact on the over all performance as scripts are marked on an object level as to which interpreter they belong to and then run in the appropriate interpreter which, in turn has its own variables. Consequently, Mudlet events are not an issue as well as all types of object scripts. The few Lua call backs that are still being used should be moved to events anyways.

The only area that needs to be especially taken care of is ATCP and GMCP variables as setting them twice for 2 different interpreters clearly has a negative impact on performance - especially as GMCP traffic can be quite substantial. Here we need to carefully look at all the available options and do some benchmark tests before we come up with a solution. There will certainly be options to disable Lua or Python GMCP/ATCP support as well as entirely disabling all Python scripting support for those who want maximum performance.

All things considered, Python scripting support imho is a very nice feature and I'm sure that many users will like it.