translating own language to shared lib
Hi! It's my very first question posted to mailing lists so please correct me if I am doing something wrong. I have subscribed to python mailing lists with araud@mail.ru address (which is mirrored to gmail) but I am writing from sasharaud@gmail.com - I don't know if it matters or not. Anyways, question is next: Is there anywhere a minimal working example of an own language translated to shared library, not standalone executable? (I saw standalone example and it worked for me, now I need more :) ) What I need is to make a problem-specific extension written in RPython that is densely integrated with exiting C++ code (quite a big product). Requirements are next: the result has to be a library (.dll and .so: product is cross-platform) with C interface (not executable). Library will be loaded by C++ code and will be called as if it was written in C: calls always come from product threads (but during calls the library can call given callbacks). I know that this is possible because cpyext does it. But cpyext is too big to understand minimal required set of actions for: * declaring target as shared lib, not standalone * running translation with proper arguments (seems like "-shared" is not enough as I get this: [translation:WARNING] target specific arguments supplied but will be ignored: -shared) * declaration of API (I saw decorators but I didn't get if decorator is enough or anything else like function registration is required) If there's no ready example I can create and publish example based on my investigation. But I still need someone's help to answer questions above. Thanks in advance! With respect, Alexander.
Hi Araud, On Thu, Jan 3, 2013 at 8:30 AM, Александр Рауд <sasharaud@gmail.com> wrote:
Is there anywhere a minimal working example of an own language translated to shared library, not standalone executable?
As we discussed on irc: you need "translate.py --shared targetfoobar.py". This makes a .dll and a .exe. The interface of the .dll is very basic: it has just one "entry point" function that is called by the .exe. I doubt it is enough for your purpose, where you want two-way communications between the "libfoobar.dll" and your C++ program. This is not supported so far. I could imagine to split this function into a few, like "initialize yourself" and "run". You could pass extra arguments to the "initialize" function, like a pointer to a table of function pointers, which the dll stores somewhere and uses to call back C++. This is all work that you would need to do yourself, though. (Finally, the issue of Win64 not being supported for now: it's not going to magically solve itself. Someone needs to step forward and fix it, which is work too.) A bientôt, Armin.
Hi, Regarding your other question: "how to embed PyPy in C/C++ application", missing _Py_Initialize. It's not supported for now but could be, given enough work. Here is an alternative, assuming that you don't need to have an interface compatible with CPython (the PyXxx functions). We could come up with some cffi-based solution (http://cffi.readthedocs.org/). For example, with minimal amount of work, we could give you the possibility to do something like this: * The C/C++ code loads "libpypy-c.dll" and calls some function 'initialize("initial_script.py")'. (Or, running on CPython, it would load "libpython27.dll" and call _PyInitialize(); PyRun_File("initial_script.py");.) * initial_script.py uses CFFI in a slightly different way than documented above (the other way around, basically): it declares a C interface, but with C functions that end up calling back into Python. (These C functions themselves are not meant to be called *from* Python.) * Then initial_script.py finishes and returns the name of the library built by "ffi.verify()". * The C/C++ side then loads and uses that library --- a regular-looking C library with whatever custom C API that you declared above. The trick is that this lets you write a regular library that can be called from C, with the C API you choose, but *implemented as Python code*. I imagine that this could be generally interesting. A bientôt, Armin.
participants (2)
-
Armin Rigo -
Александр Рауд