Jump to page: 1 2 3
Thread overview
autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
Apr 18, 2018
Atila Neves
Apr 18, 2018
jmh530
Apr 21, 2018
karita
Apr 23, 2018
Laeeth Isharc
May 10, 2018
Nikos
May 10, 2018
Nikos
May 11, 2018
Laeeth Isharc
May 11, 2018
Atila Neves
May 12, 2018
Nikos
May 13, 2018
Nikos
May 14, 2018
Laeeth Isharc
May 14, 2018
Laeeth Isharc
Jun 24, 2018
Nikos
Jul 29, 2018
Nikos
Jul 29, 2018
Nikos
Jul 31, 2018
Nicholas Wilson
Jul 31, 2018
jmh530
Aug 05, 2018
Nikos
Aug 05, 2018
Laeeth Isharc
Aug 06, 2018
Nicholas Wilson
Aug 09, 2018
Nicholas Wilson
April 18, 2018
http://code.dlang.org/packages/autowrap

This came out of the need at work to take existing D code and make it available for both Excel and Python.

Both pyd and excel-d make the reasonable assumption that one is using them to write code specifically for those environments. That breaks when there's existing production D code one wants to wrap.

The idea is to not "dirty" the existing code with dependencies on either pyd or excel-d and instead wrap them from outside the existing dub packages, whilst still using pyd and excel-d behind the scenes.

The end result is that if you have two D modules called `my.module1` and `my.module2` and you want to create a Python extension called `mylibrary`, then one dub.sdl and one source/app.d such as this is enough:


    import autowrap.python;
    mixin(
        wrapAll(
            LibraryName("mylibrary"),
            Modules("my.module1", "my.module2", /* ... */),
        )
    );

Seriously, that's it.* Well, other than the fact that dub will produce libmylibrary.so on Linux and what you need is mylibrary.so, so you'll have to rename the file.

The functions that are to be enabled for wrapping must be marked `export`, both for Python and Excel. It is a form of tagging and the production code must be changed to accomodate it, but at least it introduces no extra dependencies.

For Python, any struct used in an `export` function's parameters or return type is automatically wrapped, as well as any structs inside it.


Atila


* Except maybe for those pesky bug things I can't seem to get rid of.

April 18, 2018
On Wednesday, 18 April 2018 at 15:28:07 UTC, Atila Neves wrote:
> http://code.dlang.org/packages/autowrap
>
> This came out of the need at work to take existing D code and make it available for both Excel and Python.
>
> [snip]

Cool. I bet something similar would work with embedr as well.
April 21, 2018
On Wednesday, 18 April 2018 at 15:28:07 UTC, Atila Neves wrote:
> http://code.dlang.org/packages/autowrap
>
> This came out of the need at work to take existing D code and make it available for both Excel and Python.
>
> [...]

Awesome. I'm also working on numpy.ndarray <-> mir.ndslice automatic wrapper

https://github.com/ShigekiKarita/mir-pybuffer
April 23, 2018
On Wednesday, 18 April 2018 at 15:28:07 UTC, Atila Neves wrote:
> http://code.dlang.org/packages/autowrap
>
> This came out of the need at work to take existing D code and make it available for both Excel and Python.
>
> Both pyd and excel-d make the reasonable assumption that one is using them to write code specifically for those environments. That breaks when there's existing production D code one wants to wrap.
>

https://www.reddit.com/r/programming/comments/8eb12m/autowrap_v001_automatically_wrap_existing_d_code/
May 10, 2018
Interesting stuff.

In http://code.dlang.org/packages/autowrap it says:

"""
 Python versions

Since autowrap depends on PyD, the python version must be explicitly stated as a dub configuration and defaults to 3.6. To use another version, pass -c $CONFIG to dub where $CONFIG is one of:

    python27
    python34
    python35
    python36
"""

Could you please provide an example of how can I do this?

Thanks


May 10, 2018
In my dub.sdl file I have

> configuration "python35" {
>  subConfiguration "autowrap" "python35"
>}

and I run

> dub build --config=python35

which still tries to find python36. Why doesn't it look for 3.5?

May 11, 2018
On Thursday, 10 May 2018 at 19:50:40 UTC, Nikos wrote:
> In my dub.sdl file I have
>
>> configuration "python35" {
>>  subConfiguration "autowrap" "python35"
>>}
>
> and I run
>
>> dub build --config=python35
>
> which still tries to find python36. Why doesn't it look for 3.5?

Hi.  On my phone so can't copy paste.  Edit your dub.sdl under the python35 subconfiguration and change python 36 to python35.
May 11, 2018
On Thursday, 10 May 2018 at 19:50:40 UTC, Nikos wrote:
> In my dub.sdl file I have
>
>> configuration "python35" {
>>  subConfiguration "autowrap" "python35"
>>}
>
> and I run
>
>> dub build --config=python35
>
> which still tries to find python36. Why doesn't it look for 3.5?

Copy + paste error, sorry. Fixed now.

Atila
May 12, 2018
On Friday, 11 May 2018 at 14:16:15 UTC, Atila Neves wrote:
> On Thursday, 10 May 2018 at 19:50:40 UTC, Nikos wrote:
>> In my dub.sdl file I have
>>
>>> configuration "python35" {
>>>  subConfiguration "autowrap" "python35"
>>>}
>>
>> and I run
>>
>>> dub build --config=python35
>>
>> which still tries to find python36. Why doesn't it look for 3.5?
>
> Copy + paste error, sorry. Fixed now.
>
> Atila

That worked like a charm! Thanks man!
May 13, 2018
I'm trying to wrap drepl (https://github.com/dlang-community/drepl)

My dub.sdl files is

>import autowrap.python;
>mixin(
>    wrapAll(
>        LibraryName("drepl"),
>        Modules("drepl.interpreter"),
>    )
>);

I also flagged `export` the interpreter function

>export Interpreter!Engine interpreter(Engine)(return scope Engine e) if (isEngine!Engine)
>{
>    // workaround Issue 18540
>    return Interpreter!Engine(() @trusted { return move(e); }());
>}

I build the library with python35, but when I import it from python idle, I cannot access the `interpreter` function at all.
I have the feeling I miss something essential here, but I don't know what it is.
Any ideas?
« First   ‹ Prev
1 2 3