Hi Russel,
(Parts of this get a little technical, so the casual user may want to
ignore it)
> I should perhaps be explicit about what I am doing here so as to give
> context!
>
> I want to call Chapel code from Python code in the same way I can call
> C++ or D code. I have two modes of use: 1. call into a shared object /
> dynamic link library that exposes C linkage entry points using CFFI as
> the bridge; and 2. create a fully compiled Python extension so as to
> call in directly.
>
> I believe, but haven't checked yet, that PyChapel can do 2 – I have to
> admit I am not a fan of using comments to embed Chapel code into Python
> code, very hard to edit and maintain the Chapel code. I know PuCUDA and
> PyOpenCL support this model, I am not keen on it there either! Rather I
> prefer to have Chapel and OpenCL code in separate files and have a more
> explicit compilation and linking activity.
From what you described, it sounds like PyChapel can do 2. Luckily, we
support both the
embedded comment form and an included source file form (though it is
more work to
make sure that PyChapel knows where to look for the source files. We
have an action
item to make that compilation friendlier, but there are many things that
are higher on the
list).
>> int main(int argc, char* argv) {
>> chpl_library_init(...)
> This implies I need a C proxy to initialize the Chapel runtime system
> prior to running Chapel code. GIven I have C linkage Chapel entry
> points, can the calls be in what is supposed to be Chapel code?
Maybe? It's not something I've tried before. In particular, I'm not
certain whether the extern C declarations need to be matched against a
.h file earlier in our compiler than the generated C code is created, so
we might not have the module init function declarations present for the
code to be valid, though the runtime functions will be.
>
> This initialization function doesn't seem to be included in the Chapel
> compilation by default. I shall hunt out the document Brad referred to
> and do more research…
It's an alternative pathway. Both Chapel executable initialization and
this library init call have common subcode, but the executable
initialization does additional actions and there's a different
organization within them. PyChapel makes use of the library init call
(though it does this in a more complicated way than the psuedocode I
gave describes. The call comes from within Python code, I believe).
>
> I am hoping just to have Python and Chapel code without extra C code
> over and above the CFFI stuff.
>
>> chpl__init_MODULE_1(LINE, FILENAME)
>> ...
>> chpl__init_MODULE_N(LINE, FILENAME)
>>
>> call_chapel_function_from_MODULE_1()
>> ...
>> call_chapel_function_from_MODULE_N()
>>
>> chpl_library_finalize()
>> }
> I am guessing that solving chpl_library_init isue will solve this one :
> -)
>
Since the chpl__init_MODULE_N functions are generated during
compilation, these may be the trouble point rather than the
chpl_library_init and chpl_library_finalize calls (for the reasons I
described above).
Hope that helps,
Lydia
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
