<br><br><div class="gmail_quote">On Tue, Dec 7, 2010 at 11:34 AM, Jason McCampbell <span dir="ltr"><<a href="mailto:jmccampbell@enthought.com">jmccampbell@enthought.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Sorry for the late reply... I missed this thread. Thanks to Ilan for pointing it out. A variety of comments below...<div><br></div><div><font face="arial, sans-serif"><font color="#500050"><span style="border-collapse: collapse;">On Sat, Dec 4, 2010 at 10:20 AM, Charles R Harris<</span></font><a href="mailto:charlesr.harris@gmail.com" style="color: rgb(64, 100, 128); border-collapse: collapse; font-size: 13px;" target="_blank">charlesr.harris@gmail.com</a><font color="#500050"><span style="border-collapse: collapse;">> wrote:</span></font><br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<span style="color: rgb(80, 0, 80);">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.</span></blockquote>
</font></div><div><font face="arial, sans-serif"><span style="border-collapse: collapse;"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse: collapse;">For the purposes of our immediate project t</span></font><span style="font-family: arial,sans-serif; border-collapse: collapse;">he 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.</span></div>
<div><span style="font-family: arial,sans-serif; border-collapse: collapse;"><br></span></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; border-collapse: collapse;"></span></div>
<div><span style="font-family: arial,sans-serif; border-collapse: collapse;">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.</span></div>
<div><span style="font-family: arial,sans-serif; border-collapse: collapse;"><br></span></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; border-collapse: collapse;"></span></div>
<div><span style="font-family: arial,sans-serif; border-collapse: collapse;">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.</span></div>
<div><font face="arial, sans-serif"><span style="border-collapse: collapse;"><br></span></font></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><font face="arial, sans-serif"><span style="border-collapse: collapse;"></span></font><div class="gmail_quote">
<div><div></div><div class="h5">On Sat, Dec 4, 2010 at 3:01 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br><br><div class="gmail_quote"><div>On Sat, Dec 4, 2010 at 1:45 PM, Pauli Virtanen <span dir="ltr"><<a href="mailto:pav@iki.fi" target="_blank">pav@iki.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Sat, 04 Dec 2010 14:24:49 -0600, Ilan Schnell wrote:<br>
> I'm not sure how reasonable it would be to move only libndarray into the<br>
> master, because I've been working on EPD for the last couple of week.<br>
> But Jason will know how complete libndarray is.<br>
<br>
</div>The main question is whether moving it will make things easier or more<br>
difficult, I think. It's one tree more to keep track of.<br>
<br>
In any case, it would be a first part in the merge, and it would split<br>
the hunk of changes into two parts.<br>
<br></blockquote></div><div><br>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.<br>
<br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
***<br>
<br>
Technically, the move could be done like this, so that merge tracking<br>
still works:<br>
<br>
--------refactor--------------- new-refactor<br>
/ /<br>
/--------libndarray----------x<br>
/ \<br>
start---------------------- master----- new-master<br>
<br></blockquote></div><div><br>Looks good to me.<br></div></div></blockquote><div><br></div></div></div><div>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?</div>
<div><br></div></div></div></blockquote><div><br>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.<br> <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="gmail_quote"><div></div><div>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.</div>
<div class="im">
<div><div><div style="border-collapse: collapse; color: rgb(80, 0, 80); font-family: arial,sans-serif; font-size: 13px;"><br></div></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.</blockquote>
<div style="border-collapse: collapse; font-family: arial,sans-serif; font-size: 13px;">
<br></div></div></div></div>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. </div>
<div><br></div><div>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. </div>
<div><br></div></blockquote><div><br>There probably needs to be some discussion of a release schedule so we can plan ahead.<br><br>Chuck <br></div></div>