[Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

[Jason McCampbell]

Sorry for the late reply... I missed this thread.  Thanks to Ilan for
pointing it out.  A variety of comments below...

On Sat, Dec 4, 2010 at 10:20 AM, Charles R Harris<charlesr.harris at gmail.com>
wrote:

> Just wondering if this is temporary or the intention is to change the
> build process? I also note that the *.h files in libndarray are not complete
> and a *lot* of trailing whitespace has crept into the files.


For the purposes of our immediate project the intent is to use autoconf
since it's widely available and makes building this part Python-independent
and easier than working it into both distutils and numscons.  Going forward
it's certainly open to discussion.

Currently all of the .h and .c files are generated as a part of the build
rather than being checked in just because it saves a build step.  Checking
in the intermediate files isn't a problem either.

Does the trailing whitespace cause problems?  We saw it in the coding
guidelines and planned to run a filter over it once the code stabilizes, but
none of us had seen a guideline like that before and weren't sure why it was
there.

On Sat, Dec 4, 2010 at 3:01 PM, Charles R Harris
<charlesr.harris at gmail.com>wrote:

>
>
> On Sat, Dec 4, 2010 at 1:45 PM, Pauli Virtanen <pav at iki.fi> wrote:
>
>> On Sat, 04 Dec 2010 14:24:49 -0600, Ilan Schnell wrote:
>> > I'm not sure how reasonable it would be to move only libndarray into the
>> > master, because I've been working on EPD for the last couple of week.
>> > But Jason will know how complete libndarray is.
>>
>> The main question is whether moving it will make things easier or more
>> difficult, I think. It's one tree more to keep track of.
>>
>> In any case, it would be a first part in the merge, and it would split
>> the hunk of changes into two parts.
>>
>>
> That would be a good thing IMHO. It would also bring a bit more numpy
> reality to the refactor and since we are implicitly relying on it for the
> next release sometime next spring the closer to reality it gets the better.
>
>
>>    ***
>>
>> Technically, the move could be done like this, so that merge tracking
>> still works:
>>
>>           --------refactor--------------- new-refactor
>>          /                            /
>>         /--------libndarray----------x
>>        /                              \
>>   start---------------------- master----- new-master
>>
>>
> Looks good to me.
>

Doing this isn't a problem, though I'm not sure if it buys us much.  90% of
the changes are the refactoring, moving substantial amounts of code from
numpy/core/src/multiarray and /umath into libndarray and then all of the
assorted fix-ups.  The rest is the .NET interface layer which is isolated in
numpy/NumpyDotNet for now.  We can leave this directory out, but everything
else is the same between libndarray and refactor. Or am I misunderstanding
the reason?

The current state of the refactor branch is that it passes the bulk of
regressions on Python 2.6 and 3.? (Ilan, what version did you use?) and is
up-to-date with the master branch.  There are a few failing regression test
that we need to look at vs. the master branch but less than dozen.

Switching to use libndarray is a big ABI+API change, right?  If there's an
> idea to release an ABI-compatible 1.6, wouldn't this end up being more
> difficult?  Maybe I'm misunderstanding this idea.


Definitely a big ABI change and effectively a big API change.  The API
itself should be close to 100% compatible, except that the data structures
all change to introduce a new layer of indirection.  Code that strictly uses
the macro accessors will build fine, but that is turning out to be quite
rare. The changes are quite mechanical but still non-trivial for code that
directly accesses the structure fields.

Changes to Cython as a part of the project take care of some of the work. A
new numpy.pdx file is needed and will mask the changes as long as the Python
(as opposed to the CPython) interface is used.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20101207/87a072b4/attachment.html>