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

Charles R Harris charlesr.harris@gmail....
Tue Dec 7 12:57:13 CST 2010


On Tue, Dec 7, 2010 at 11:34 AM, Jason McCampbell <jmccampbell@enthought.com
> wrote:

> 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@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.
>
>
Yes, maintaining multiple build systems is a hassle. I'm wondering if we
shouldn't remove the scons stuff and stick with distutils until we
definitely decide there is a better way. As to autotools, I think it is a
fine short term solution for development purposes, but probably needs to be
replaced down the road.


> 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.
>
>
The idea of having separate .h files is that you can test compile without a
complete build. They might also be helpful in the separate compilation case
(I haven't checked). But in any case, the *.h.src files are there just to
make maintaining the .h file easier, they shouldn't be used as part of the
build.


> 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.
>
>
It should be cleaned up before anything becomes official. Git can be set up
to warn about trailing whitespace. The general guideline is no trailing
whitespace. For one thing you end up with repository changes that
unintentionally involve whitespace. Most editors can be set up to flag
trailing whitespace, which will increase the desire to keep the file clean.

On Sat, Dec 4, 2010 at 3:01 PM, Charles R Harris
<charlesr.harris@gmail.com>wrote:
>
>>
>>
>> On Sat, Dec 4, 2010 at 1:45 PM, Pauli Virtanen <pav@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 idea is to keep things moving along and maybe encourage others to take a
bigger role in the merge. We wouldn't touch the current master branch of
numpy yet.


> 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.
>
>
There probably needs to be some discussion of a release schedule so we can
plan ahead.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20101207/4eb6c5d3/attachment-0001.html 


More information about the NumPy-Discussion mailing list