Ellery Newcomer:

>> array.array <==> D arrays
>
> just checked, looks like we have it:
>
> PyStmts(q"{from array import array; a = array('i', [44,33,22,11]);}", "testing");
> assert(PyEval!(int[])("a", "testing") == [44,33,22,11]);
>
> I think if the python object is iterable, it can be converted to array.

array.array are special, they aren't Python lists. array.array contains uniform data, so conversion to D arrays is a memcpy (or it's nearly nothing if you don't copy the data).

Bye,
bearophile

On 09/05/2012 11:19 PM, Jacob Carlborg wrote:
> On 2012-09-06 04:10, bearophile wrote:
>
>> There are several important cases, like:
>>
>> Some D lazy ranges <==> Python lazy iterators/generators
>>
>> array.array <==> D arrays
>>
>> NumPy arrays <==> D arrays
>
> Associative arrays?
>

check.

https://bitbucket.org/ariovistus/pyd/wiki/TypeConversion

On 09/06/2012 04:11 AM, bearophile wrote:
> Ellery Newcomer:
>
>>> array.array <==> D arrays
>>
>> just checked, looks like we have it:
>>
>> PyStmts(q"{from array import array; a = array('i', [44,33,22,11]);}",
>> "testing");
>> assert(PyEval!(int[])("a", "testing") == [44,33,22,11]);
>>
>> I think if the python object is iterable, it can be converted to array.
>
> array.array are special, they aren't Python lists. array.array contains
> uniform data, so conversion to D arrays is a memcpy (or it's nearly
> nothing if you don't copy the data).
>
> Bye,
> bearophile

I see. The docs for array.array suggest that it implements the buffer interface, but it doesn't seem to implement new or old style buffers, at least according to PyObject_CheckBuffer and PyBuffer_Check.

I think I'll add support for new style buffers anyways. a memoryview would be good, too.

Guess I'll hack together a special case for array using buffer_info.

On 09/06/2012 09:48 AM, Ellery Newcomer wrote:
> On 09/05/2012 11:19 PM, Jacob Carlborg wr
>>
>> Associative arrays?
>>
>
> check.
>

eh, that was check as in yes, not check as in look it up yourself.

didn't seem ambiguous at the time.

On 09/06/2012 12:07 AM, Russel Winder wrote:
>
> I am guessing this is interfacing to CPython, remember there is also
> PyPy and ActiveState, they have different ways of doing things.  Well
> the ActiveState C API will be very close to the CPython C API, but PyPy
> (which is the best Python 2.7 just now) doesn't have a C API since it is
> written in RPython.

Yep, CPython for now. If activestate supports the CPython C API, then supporting it will probably just be a matter of linkage.

Googling, it looks like PyPy is/was trying to grow some CPython C API compatibility, so hopefully we can squeeze it in at some point.

>
> Oh yes.
>
> NumPy is basically a subsystem that Python applications make calls into.
> Although the data structure can be accessed and amended, algorithms on
> the data structures should never be written in Python, they should
> always be function calls into the NumPy framework.

I had a look at numpy, and at least ndarray supports the new style buffer interface (which is pretty freaking complicated), so convertion is totally doable. I'll fold in support as soon as I can get dmd to stop stabbing me in the face.


just used your scons fork to build the pyd embedded unittests. works pretty nice

Ellery Newcomer:

> I had a look at numpy, and at least ndarray supports the new style buffer interface (which is pretty freaking complicated), so convertion is totally doable. I'll fold in support as soon as I can get dmd to stop stabbing me in the face.

If you support NumPy well and efficiently through Pyd, I think some people will start using the D language just for this :-)

NumPy is good but it usually forces you to program vectorially, like Matlab. Sometimes this is not nice, so people write some routines in Fortran, C, etc. With Pyd some scientific programmers maybe will want to use D instead.

Bye,
bearophile

On Sat, 2012-09-08 at 00:58 +0200, bearophile wrote:
[…]
> If you support NumPy well and efficiently through Pyd, I think some people will start using the D language just for this :-)
> 
> NumPy is good but it usually forces you to program vectorially, like Matlab. Sometimes this is not nice, so people write some routines in Fortran, C, etc. With Pyd some scientific programmers maybe will want to use D instead.

The idea of a Python/NumPy/D combination, especially if connected to OpenCL does have great appeal. NumPy and D for computation and Python for data visualization and coordination would be an improvement over the currently canonical Python/NumPy/C/C++/Fortran. But there is a large inertia to the system that has built up in the bioinformatics and HEP communities.
-- 
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 Fri, 2012-09-07 at 15:21 -0700, Ellery Newcomer wrote:
> On 09/06/2012 12:07 AM, Russel Winder wrote:
[…]
> just used your scons fork to build the pyd embedded unittests. works pretty nice

Splendid :-)

If you see any problems or glitches, let me know and/or post a bug report.  Although I said use the BitBucket issue system, that was a hang over from the days of a totally separate package for the D system. Now that D support is being evolved as a fork, it has been pointed out to me I should have pointed people to the SCons issue tracker http://scons.tigris.org/project_issues.html for posting reports about D tooling issues as they are in the SCons core.

-- 
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 09/08/2012 03:09 AM, Russel Winder wrote:
> On Fri, 2012-09-07 at 15:21 -0700, Ellery Newcomer wrote:
>> On 09/06/2012 12:07 AM, Russel Winder wrote:
> […]
>> just used your scons fork to build the pyd embedded unittests. works
>> pretty nice
>
> Splendid :-)
>

Okay, here: https://bitbucket.org/ariovistus/deimos-elfutils/overview

I have some code with a working makefile and a nonworking SConstruct file.

I believe the issue is the header files have pragma(lib, X) in them, and a single call to dmd links the appropriate lib in, but scons' link step loses that information.

Do you have any intention of supporting pragma(lib) in scons?

On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote: […]
> Okay, here: https://bitbucket.org/ariovistus/deimos-elfutils/overview
> 
> I have some code with a working makefile and a nonworking SConstruct file.
> 
> I believe the issue is the header files have pragma(lib, X) in them, and a single call to dmd links the appropriate lib in, but scons' link step loses that information.
> 
> Do you have any intention of supporting pragma(lib) in scons?

If that is valid Dv2 and SCons doesn't deal with it then the SCons D tools are broken and need fixing.

Is there a tiny project replicating this that I can turn into a unit/system test. The red so caused will necessitate action :-)

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