An unusually positive thread on D:

http://www.reddit.com/r/Python/comments/12w2i4/have_you_used_python_with_d/

Bye,
bearophile

On 11/09/2012 07:03 AM, bearophile wrote:
> An unusually positive thread on D:
>
> http://www.reddit.com/r/Python/comments/12w2i4/have_you_used_python_with_d/
>
> Bye,
> bearophile

He's been writing python extensions in C; he *should* be happy :)

btw, what's the status on druntime support for shared libraries? Pyd is kind of walking on thin ice until this is straightened out.

On Saturday, 10 November 2012 at 00:31:53 UTC, Ellery Newcomer wrote:
> On 11/09/2012 07:03 AM, bearophile wrote:
>> An unusually positive thread on D:
>>
>> http://www.reddit.com/r/Python/comments/12w2i4/have_you_used_python_with_d/
>>
>> Bye,
>> bearophile
>
> He's been writing python extensions in C; he *should* be happy :)
>
> btw, what's the status on druntime support for shared libraries? Pyd is kind of walking on thin ice until this is straightened out.

I'm also gambling that the dll issue will be resolved in a reasonable amount of time, as the apps I'm building in D will require it. I'll need ddl's that are dynamically linked, and ddl's used as plugins that are dymaically loaded.

I'm currently working on Linux almost exclusively, which also has the same problem.

Unfortunately, I'm very new to D, so I doubt at this stage I can lend a hand to help solve problems like the dll issue. The best I can do for now is report on compiler bugs that I'm finding.

--rt

On Fri, 2012-11-09 at 16:31 -0800, Ellery Newcomer wrote: […]
> He's been writing python extensions in C; he *should* be happy :)

It is true that most people just use Cython these days.

Or they are using NumPy, Numba, etc.

> btw, what's the status on druntime support for shared libraries? Pyd is kind of walking on thin ice until this is straightened out.

This and another problem is why I have hesitated mentioning D as a tool for writing CPython extensions in my Python workshops: the extensions are CPython specific and will not work with PyPy (or Jython but that is a whole other set of issues).

What is guaranteed now is that the ctypes package works in CPython and PyPy and would seem to be the right "API" for people interested in using Python with D.  If the ctypes overhead is significant to the execution then writing a native code extension is probably the wrong solution to the problem?

-- 
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, 10 November 2012 at 06:22:57 UTC, Rob T wrote:
> I'm also gambling that the dll issue will be resolved in a reasonable amount of time, as the apps I'm building in D will require it. I'll need ddl's that are dynamically linked, and ddl's used as plugins that are dymaically loaded.
>
> I'm currently working on Linux almost exclusively, which also has the same problem.
>
> Unfortunately, I'm very new to D, so I doubt at this stage I can lend a hand to help solve problems like the dll issue. The best I can do for now is report on compiler bugs that I'm finding.

Although I've only tested on Windows, I have a working DLL module example in LuaD [1][2]. The problems with DLLs are not as relevant for modules like these, and I don't imagine Python modules having too different needs.

[1] https://github.com/JakobOvrum/LuaD/tree/master/example/dmodule
[2] https://github.com/JakobOvrum/LuaD/blob/master/example/bin/module.lua

On 11/09/2012 11:33 PM, Russel Winder wrote:
>
> What is guaranteed now is that the ctypes package works in CPython and
> PyPy and would seem to be the right "API" for people interested in using
> Python with D.  If the ctypes overhead is significant to the execution
> then writing a native code extension is probably the wrong solution to
> the problem?
>

Never used ctypes. How difficult would it be to get python objects/functions to the extension side?

On Sat, 2012-11-10 at 14:08 -0800, Ellery Newcomer wrote: […]
> Never used ctypes. How difficult would it be to get python objects/functions to the extension side?

As long as the code compiles to a shared object/dynamic link library and presents C-linkage entry points, Python code can call the entry points through ctypes. C++ codes just provide C-linkage entries, D codes just provide C-linkage entries. The real issue is that it must be a shared object or dynamic link library.
-- 
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

Just tried building a shared library on linux with dmd (and calling it from C).

It works! Holy crap, it even runs my static constructors and unittests! I only had to screw with the linking process a little bit!

It doesn't work for x64, though. Gives me

/usr/bin/ld: /usr/lib64/dmd/libphobos2.a(object__c_58c.o): relocation R_X86_64_32 against `_D10TypeInfo_m6__initZ' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/dmd/libphobos2.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
--- errorlevel 1

Though why it doesn't do this for x32 is beyond me. Those object files don't appear to be -fPIC either.

On Thursday, 15 November 2012 at 02:51:08 UTC, Ellery Newcomer wrote:
> Just tried building a shared library on linux with dmd (and calling it from C).
>
> It works! Holy crap, it even runs my static constructors and unittests! I only had to screw with the linking process a little bit!
>
> It doesn't work for x64, though. Gives me
>
> /usr/bin/ld: /usr/lib64/dmd/libphobos2.a(object__c_58c.o): relocation R_X86_64_32 against `_D10TypeInfo_m6__initZ' can not be used when making a shared object; recompile with -fPIC
> /usr/lib64/dmd/libphobos2.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> --- errorlevel 1
>
> Though why it doesn't do this for x32 is beyond me. Those object files don't appear to be -fPIC either.

You can dynamically link to D shared libraries on linux (http://forum.dlang.org/thread/k3vfm9$1tq$1@digitalmars.com?page=2). The message you receive actually means that you cannot make a shared library from current version of Phobos and Druntime due to how they are compiled. However I saw several people working on making druntime shared. The solution is not to put druntime in .so file.

I tried to investigate which features do not work with dynamic linking (not loading) and found certainly one - it is related to not invoking scope(XXX) statements at some circumstances.