Hello all,

Can anyone advise on where things stand with PyD, in terms of Python version(s)
supported, D version(s) supported, general up-to-dateness and stability?

The writeups on the Dsource page <http://pyd.dsource.org/> look like they
haven't been maintained in a long time, so I presume the Bitbucket repo is now
the current up-to-date location?
https://bitbucket.org/ariovistus/pyd

According to that page it's supported on Linux with Python 2.7 and LDC, with GDC status unknown.  Are the support issues here down to backend, or is it the frontend version that matters?  Is it possible to link against PyD built with LDC with D code built with GDC?

Also, given that the API is being updated, how reliable/stable are PyD/CeleriD right now?

Finally, any advice on uninstallation/installing new versions when the source is updated?  Python novice here. :-)

For those who are curious, my particular interest is in using this library in conjunction with D: http://networkx.github.com/  Don't suppose anyone has already tried this and has experience to share?

Thanks & best wishes,

    -- Joe

Hi.

Yes, the bitbucket repo is up to date (or was, a month ago. I've been a bit busy..).

It looks like you want to embed python into D, in which case the situation is better than the main page suggests. Pyd supports

* CPython - 2.4 through 3.2
* dmd 2.060+
* ldc {whatever is based on dmdfe 2.060+}

on linux.

Somehow I still haven't gotten around to building gdc yet, but supporting gdc for embedding python would just be a matter of updating the CeleriD configurations and ensuring everything links. Might as well do that tonight. Stay tuned.

Pyd is pretty reliable. I try to avoid making changes to the API, but there were a few when I implemented python3 support. There will probably be a few more when I tackle PyPy.

On 04/03/2013 05:27 AM, Joseph Rushton Wakeling wrote:
> Hello all,
>
> Can anyone advise on where things stand with PyD, in terms of Python version(s)
> supported, D version(s) supported, general up-to-dateness and stability?
>
> The writeups on the Dsource page <http://pyd.dsource.org/> look like they
> haven't been maintained in a long time, so I presume the Bitbucket repo is now
> the current up-to-date location?
> https://bitbucket.org/ariovistus/pyd
>
> According to that page it's supported on Linux with Python 2.7 and LDC, with GDC
> status unknown.  Are the support issues here down to backend, or is it the
> frontend version that matters?  Is it possible to link against PyD built with
> LDC with D code built with GDC?
>
> Also, given that the API is being updated, how reliable/stable are PyD/CeleriD
> right now?
>
> Finally, any advice on uninstallation/installing new versions when the source is
> updated?  Python novice here. :-)
>
> For those who are curious, my particular interest is in using this library in
> conjunction with D: http://networkx.github.com/  Don't suppose anyone has
> already tried this and has experience to share?
>
> Thanks & best wishes,
>
>      -- Joe
>

On 04/03/2013 05:58 PM, Ellery Newcomer wrote:
>
> Somehow I still haven't gotten around to building gdc yet, but
> supporting gdc for embedding python would just be a matter of updating
> the CeleriD configurations and ensuring everything links. Might as well
> do that tonight. Stay tuned.
>

Actually, it looks like pyd is working just fine with gdc built from master, so have some randomly diced NetworkX Quick Example:

// thimble.d

import std.stdio;
import pyd.pyd, pyd.embedded;

void main() {
    py_init();

    auto ctxt = new InterpContext();
    ctxt.py_stmts("import networkx as nx");
    ctxt.py_stmts(q"<
G=nx.Graph()
G.add_node("spam")
>");
    ctxt.G.add_edge(1,2);
    ctxt.py_stmts("print(G.nodes())");
    // **(^*(& corner case with properties
    writeln(ctxt.G.edges.opCall());
}

// setup.py

from celerid.support import setup, Extension

setup(
    name="thimble",
    version='1.0',
    ext_modules=[
    Extension("thimble", ["thimble.d"],
    build_deimos=True
        )
    ],
)

// command line:

> python setup.py pydexe --compiler=gdc
> ./thimble

[1L, 2L, 'spam']
[(1L, 2L)]

On 04/04/2013 05:50 AM, Ellery Newcomer wrote:
> Actually, it looks like pyd is working just fine with gdc built from master

That's what I wondered -- I was guessing that it's frontend version that matters, not backend.

> so have some randomly diced NetworkX Quick Example:

Really nice of you to put that together for me -- it's very helpful.  Thank you very much!

Hello,

Not working here on a Debian sid :

gdc -fproperty -c -fversion=Python_2_4_Or_Later -fversion=Python_2_5_Or_Later -fversion=Python_2_6_Or_Later -fversion=Python_2_7_Or_Later -fversion=Python_3_0_Or_Later -fversion=Python_3_1_Or_Later -fversion=Python_3_2_Or_Later -fversion=Python_3_3_Or_Later -fversion=Python_Unicode_UCS4 -fdebug -I /usr/local/lib/python3.3/dist-packages/celerid/infrastructure -o build/temp.linux-x86_64-3.3/infra/temp.o hello.d /usr/local/lib/python3.3/dist-packages/celerid/infrastructure/pyd/class_wrap.d /usr/local/lib/python3.3/dist-packages/celerid/infrastructure/pyd/ctor_wrap.d
...
[lot of text here, won't copy-paste everything, should I]
...
def: hello
wrap_struct: 'RangeWrapper'
class.def: __iter__
class.def: next
wrapped_struct_init, S is 'struct pyd.make_object.RangeWrapper'
library_dirs: []
runtime_library_dirs: []
libraries: ['python3.3m']
gdc -fdebug -o build/lib.linux-x86_64-3.3/hello build/temp.linux-x86_64-3.3/infra/temp.o -lpython3.3m
/usr/bin/ld: cannot find -lpython3.3m
collect2: error: ld returned 1 exit status
error: command 'gdc' failed with exit status 1

Any clue ?

Thanks

Ah, forgot to say :

I executed "python3.3 setup.py pydexe --compiler=gdc"

Any other way won't work.

tried hacking dcompiler.py in the python local packages, no luck.

Libraries won't be taken into account.
May I read something wrong..

Ok python3-dev was missing.

Now, it is a gdc problem:

[code]
def: hello
wrap_struct: 'RangeWrapper'
class.def: __iter__
class.def: next
wrapped_struct_init, S is 'struct pyd.make_object.RangeWrapper'
library_dirs: []
runtime_library_dirs: []
libraries: []
gdc -fPIC -nostartfiles -shared -fdebug -o
build/lib.linux-x86_64-3.3/hello.cpython-33m.so
build/temp.linux-x86_64-3.3/infra/temp.o
-Wl,-soname,hello.cpython-33m.so
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a(object_.o):
relocation R_X86_64_32S against `_D10TypeInfo_m6__initZ' can not
be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a: error adding
symbols: Bad value
collect2: error: ld returned 1 exit status
error: command 'gdc' failed with exit status

[/code]

This line is a mess to manage.. :
[code]
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a: error adding
symbols: Bad value
[/code]

Does anyone has a clue on what has to be done ?

I am on a Debian sid 64bits system.

On Sat, 2013-08-31 at 12:56 +0200, Larry wrote:
> Ok python3-dev was missing.

Are you using Python 3.3?

Are you using SCons or Tup for the build?

I just tried the SCons build OOTB and it fails to build PyD with DMD :-(

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 31 August 2013 at 15:44:03 UTC, Russel Winder wrote:
> On Sat, 2013-08-31 at 12:56 +0200, Larry wrote:
>> Ok python3-dev was missing.
>
> Are you using Python 3.3?
>
> Are you using SCons or Tup for the build?
>
> I just tried the SCons build OOTB and it fails to build PyD with DMD :-(

Ehh, yeah. I gave up on build systems a while back because it made it unnecessarily complicated to set up test vms for more exotic systems. Now we use

python setup.py [build|install]

because python's always there. OP has that right.

Since I've been out of the loop for a while, can gdc build shared libraries yet? That's what OP's build command is trying to do.

Am Thu, 05 Sep 2013 04:49:04 +0200
schrieb "Ellery Newcomer" <ellery-newcomer@utulsa.edu>:

> 
> Since I've been out of the loop for a while, can gdc build shared libraries yet? That's what OP's build command is trying to do.

Unfortunately no. Although the relocation error looks like a regression we never had runtime support for shared libraries, so it probably wouldn't work anyway.