• Joseph Rushton Wakeling (20/20) Apr 03 2013 Hello all,
• Ellery Newcomer (17/37) Apr 03 2013 Hi.
• Ellery Newcomer (32/39) Apr 03 2013 Actually, it looks like pyd is working just fine with gdc built from
• Joseph Rushton Wakeling (5/7) Apr 04 2013 That's what I wondered -- I was guessing that it's frontend version that
• Larry (30/30) Aug 30 2013 Hello,
• Larry (6/6) Aug 30 2013 Ah, forgot to say :
• Larry (31/31) Aug 31 2013 Ok python3-dev was missing.
• Russel Winder (14/15) Aug 31 2013 Are you using Python 3.3?
• Ellery Newcomer (8/14) Sep 04 2013 Ehh, yeah. I gave up on build systems a while back because it
• Johannes Pfau (5/8) Sep 06 2013 Unfortunately no. Although the relocation error looks like a

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

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

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

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

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

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)]

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

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!

"Larry" <deco33 hotmail.fr> writes:

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

"Larry" <deco33 hotmail.fr> writes:

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..

"Larry" <deco33 hotmail.fr> writes:

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.

Russel Winder <russel winder.org.uk> writes:

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 :-(

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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

"Ellery Newcomer" <ellery-newcomer utulsa.edu> writes:

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.

Johannes Pfau <nospam example.com> writes:

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.