complexity into a class which is small and more
> easily verifiable. This is about code quality, and the best quality C++ code
> I've worked with has been way easier to program in than the best quality C
> code I've worked with.
While I actually believe this to be true (ve
Note sure if this already has been discussed, but it seems that latest
Sphinx, 1.2predev-20120222 directly from their Hg repository, does not
have this problem any more. While 1.2 failed to build the documentation
on my end, 1.2predev delivered a result.
Regards,
David
On 24/11/11 15:31
t;real" precision. It often (but not always)
refer to the long double in the underlying C implementation. The
latter depends on the OS, CPU and compilers.
cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
of opinon :)
I don't think the code is comparable either - some of the stuff done
in the C code is done in the C++ code your are calling. The C code
could be significantly improved. Even more important here: almost none
of this code should be written any
On Sun, Mar 4, 2012 at 2:18 PM, Luis Pedro Coelho wrote:
> On Saturday, March 03, 2012 04:38:53 PM David Cournapeau wrote:
>> I don't think the code is comparable either - some of the stuff done
>> in the C code is done in the C++ code your are calling. The C code
>&
type type that will look up sizeof(long) bytes from the starting
> position of the flags member in the struct. This includes 3 bytes of
> the following type_num member. Obviously, 2048 does not fit into a
> char. Nonetheless, the type_num is also part of t
/numpy/pull/228
Which one is the more appropriate ? Maybe a deprecation warning for
1.7 and change it in 1.8 ?
Note that we can fix the hash issue with either solution,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
On Tue, Mar 6, 2012 at 6:20 AM, Robert Kern wrote:
> On Tue, Mar 6, 2012 at 03:53, David Cournapeau wrote:
>> Hi,
>>
>> This is following the discussion on bug
>> http://projects.scipy.org/numpy/ticket/2017
>>
>> Essentially, there is a discrepency between
an actual accessor if needed. Given that dtype.flags is
nonsensical as of today (at the python level), I would expect nobody
uses it.
cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Py's Python wrappers from C. Just use BLAS directly from C
> instead.
Of course it does make his life easier. This way he does not have to
distribute his own BLAS/LAPACK/etc...
Please stop presenting as truth things which are at best highly
opiniated. You already made such statements many
r identical information to what is in this list is repeated,
> without any chance of consistency or error checking, all over the place.
I don't think anyone likes it . All your points are certainly valid.
There are solutions to this that does not require C++ (Chuck worked on
that I believe, al
easily done explicitly.
>
That was not even the issue in the end, my initial analysis was wrong.
In any case, I have now a new PR that fixes both dtypes.flags value and
dtype hashing reported in #2017: https://github.com/numpy/numpy/pull/231
regards,
David
__
ure it is 16 bytes on windows
64.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
I think writing a Python script that convert your txt file to one netcdf file,
reading the txt file one line at a time, and then use the netcdf file normally
would be a good solution!
Best,
David
Excerpts from Chao YUE's message of mar. mars 20 13:33:56 +0100 2012:
> Dear all
Excerpts from Sameer Grover's message of ven. mars 09 20:50:06 +0100 2012:
> >>>import gtk
> >>>import foo # where foo is any f2py-wrapped program
>
> Subsequently, on exiting python interpreter, the interpreter crashes
> with this error message - "This application has requested the Runtime
> to t
L is a non-trivial
process, so I would rather avoid it.
If you still want to build it by yourself, could you give us the full
output of your build ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
distutils packages
relying on the package_dir feature
Bento source code can be found on github: https://github.com/cournape/Bento
Bento documentation is there as well: https://cournape.github.com/Bento
regards,
David
___
NumPy-Discussion mailing list
NumPy
it is documented explicitly in
matlab.
regards,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- I have no idea how numpy and MATLAB's random number
> generation compare, nor how random number generation compares to
> eig(), but you should profile them independently to make sure.
>
While this is true, the cost is most likely negligeable compared to the
cost of eig (
issues, Maggie or I can try and see what we can find out
>> about implementing them, or working around them, this week.
>>
>
> I'd say that from the issues I mentioned, the biggest one is the one-line
> view. So these two:
>
> - I haven't found a way yet to
On Thu, Apr 12, 2012 at 5:43 PM, Ralf Gommers
wrote:
>
>
> On Tue, Apr 10, 2012 at 9:53 PM, David Cournapeau wrote:
>
>>
>>
>> On Tue, Apr 10, 2012 at 8:40 PM, Ralf Gommers <
>> ralf.gomm...@googlemail.com> wrote:
>>
>>>
>>>
ing:
http://www.readwriteweb.com/hack/2011/09/a-look-at-phabricator-facebook.php
There is a quite complete command line interface, arcanist, and if done
right, having code review and bug tracking integrated together sounds
exciting.
Thanks for mentioning it, I will definitely look it out.
regard
On Wed, Apr 25, 2012 at 10:54 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Apr 25, 2012 at 2:35 PM, Travis Oliphant
> wrote:
> >>
> >> Do you agree that Numpy has not been very successful in recruiting and
> >> maintaining new developers compared to its large user-base?
> >>
> >> Compared to - say
l,
What about buildbot? (http://trac.buildbot.net/)
I'm using it currently, and like it because is GPL 2, configuration files are
powerful Python scripts, and development team is active and dynamic.
Best,
David
___
NumPy-Discussion mailing li
ves. After that, I plan to transfer existing slaves to the new setup,
> and then maybe ask for new volunteer slave machines (if people think the
> buildbot setup is useful).
Hi,
If there are things one can contribute to help the development of the buildbot
for NumPy
ing it and making releases. A branch in the numpy repository
>> wouldn't work since we would want to rebase it regularly. It could maybe go
>> in scipy but a new package would need to be created there and it feels too
>> distant from numpy for such basic types as da
ration, the caller may have some
> idea of how to allocate an output array. I'm not sure how to handle
> "insertions" of new elements, but I presume through vtable put/insert
> functions. I'm also not sure how to fit this in with linear algebra
> functionality, o
ng. Why not go for option 2, which will
> get 1.7 out there and push the new masked array work in to 1.8? Breaking
> the flow of development and release has consequences, few of them good.
>
Agreed. 1.6.0 was released one year ago already, let's focus on polishing
what's in there
tain it at
that point, but would be happy to give someone the keys to make it up to
date.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Not the neighborhood one, though. It would be good if this iterator had a
cython wrapper, and ndimage used that, though.
Le 13 juin 2012 18:59, "Ralf Gommers" a
écrit :
>
>
> On Wed, Jun 13, 2012 at 6:57 PM, Thouis (Ray) Jones wrote:
>
>> Hello,
>>
>> I'm rewriting scipy.ndimage.label() using num
.
- add register_metadata API to register new metadata to be filled in
MetaTemplateFile
Bento source code can be found on github: https://github.com/cournape/Bento
Bento documentation is there as well: https://cournape.github.com/Bento
regards,
David
hink that the lack of response to this
> email/PR indicates that everyone now agrees with me about how to
> proceed with the NA work, I'm for some reason unconvinced...
>
> Any objections to merging this?
>
No objection, but could you wait for this WE
On Sat, Jun 16, 2012 at 9:39 PM, Nathaniel Smith wrote:
> On Thu, Jun 14, 2012 at 5:20 PM, David Cournapeau
> wrote:
> >
> >
> > On Thu, Jun 14, 2012 at 5:17 PM, Nathaniel Smith wrote:
> >>
> >> On Wed, Jun 6, 2012 at 11:08 PM, Nathaniel Smith wrot
hough. This would be a good
starting point to check ABI matters (say pandas, mpl, scipy on top of
multiple numpy).
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Jun 26, 2012 at 4:42 AM, Ondřej Čertík wrote:
> On Mon, Jun 25, 2012 at 8:35 PM, David Cournapeau wrote:
>> On Tue, Jun 26, 2012 at 4:10 AM, Ondřej Čertík
>> wrote:
>>
>>>
>>> My understanding is that Travis is simply trying to stress "We hav
On Tue, Jun 26, 2012 at 5:17 AM, Travis Oliphant wrote:
>
> On Jun 25, 2012, at 10:35 PM, David Cournapeau wrote:
>
>> On Tue, Jun 26, 2012 at 4:10 AM, Ondřej Čertík
>> wrote:
>>
>>>
>>> My understanding is that Travis is simply trying to stress &q
On Tue, Jun 26, 2012 at 10:27 AM, Dag Sverre Seljebotn
wrote:
> On 06/26/2012 05:35 AM, David Cournapeau wrote:
>> On Tue, Jun 26, 2012 at 4:10 AM, Ondřej Čertík
>> wrote:
>>
>>>
>>> My understanding is that Travis is simply trying to stress "We hav
Hi,
I am just continuing the discussion around ABI/API, the technical side
of things that is, as this is unrelated to 1.7.x. release.
On Tue, Jun 26, 2012 at 11:41 AM, Dag Sverre Seljebotn
wrote:
> On 06/26/2012 11:58 AM, David Cournapeau wrote:
>> On Tue, Jun 26, 2012 at 10:27 AM, D
On Tue, Jun 26, 2012 at 2:40 PM, Dag Sverre Seljebotn
wrote:
> On 06/26/2012 01:48 PM, David Cournapeau wrote:
>> Hi,
>>
>> I am just continuing the discussion around ABI/API, the technical side
>> of things that is, as this is unrelated to 1.7.x. release.
>>
&g
On Tue, Jun 26, 2012 at 5:24 PM, Travis Oliphant wrote:
>
>> Let us note that that problem was due to Travis convincing David to
>> include the Datetime work in the release against David's own best judgement.
>> The result was a delay of several months until Ralf could
ose together. I gather from comments in the source code
> that the former is the traditional method, and the latter is the newer
> "experimental" approach.
>
> It's easy to break one of these builds without breaking the other (I
> just did this with the NA branch, an
On Wed, Jun 27, 2012 at 8:07 PM, Nathaniel Smith wrote:
> On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau wrote:
>> On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith wrote:
>>> Currently the numpy build system(s) support two ways of building
>>> numpy: either by com
On Wed, Jun 27, 2012 at 8:53 PM, Nathaniel Smith wrote:
> On Wed, Jun 27, 2012 at 8:29 PM, David Cournapeau wrote:
>> On Wed, Jun 27, 2012 at 8:07 PM, Nathaniel Smith wrote:
>>> On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau
>>> wrote:
>>>> On Wed, J
On Wed, Jun 27, 2012 at 8:57 PM, Dag Sverre Seljebotn
wrote:
> On 06/27/2012 09:53 PM, Nathaniel Smith wrote:
>> On Wed, Jun 27, 2012 at 8:29 PM, David Cournapeau wrote:
>>> On Wed, Jun 27, 2012 at 8:07 PM, Nathaniel Smith wrote:
>>>> On Wed, Jun 27, 201
r ABI since a few releases would
help achieving that.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
t; machine on which memcpy goes backwards, and so the test fails whenever
> the build gets assigned to that machine. (Apparently this is actually
> faster on some CPUs, and new versions of glibc are known to exploit
> this.)
see also this: https://bugzilla.redhat.com/show_bug.cgi?id=638477
D
more information, but my
> customer is on hollidays and I just wanted to ask for some hints for
> possible
> reasons. The machine is not out of memory and despite this crash runs very
> stable.
Is this on 32 or 64 bits windows ? Do you know if your c
On Sun, Jul 1, 2012 at 6:36 PM, Nathaniel Smith wrote:
> On Wed, Jun 27, 2012 at 9:05 PM, David Cournapeau wrote:
>> On Wed, Jun 27, 2012 at 8:53 PM, Nathaniel Smith wrote:
>>> But seriously, what compilers do we support that don't have
>>> -fvisibility=hi
On Sun, Jul 1, 2012 at 8:32 PM, Nathaniel Smith wrote:
> On Sun, Jul 1, 2012 at 7:36 PM, David Cournapeau wrote:
>> On Sun, Jul 1, 2012 at 6:36 PM, Nathaniel Smith wrote:
>>> On Wed, Jun 27, 2012 at 9:05 PM, David Cournapeau
>>> wrote:
>>>> On Wed, J
array.so only is negligible for me (i.e. difference
between python -c "import multiarray" and python -c "" is
statistically insignificant).
I would check external factors, like the size of your sys.path as well.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jul 2, 2012 at 11:15 PM, Andrew Dalke wrote:
> On Jul 2, 2012, at 11:38 PM, Fernando Perez wrote:
>> No, that's the wrong thing to test, because it effectively amounts to
>> 'import numpy', sicne the numpy __init__ file is still executed. As
>&
cannot find my patch for detecting platforms where this can safely
become the default, I will reprepare one.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
---
>> Traceback (most recent call last):
>> File "C:\Python26\lib\site-packages\nose\loader.py", line 382, in
>> loadTestsFromName
>> addr.filename, addr.module)
>> File "C:\Python26
Hi, folks! Having a problem w/ the Windows installer; first, the
"back-story": I have both Python 2.7 and 3.2 installed. When I run the
installer and click next on the first dialog, I get the message that I need
Python 2.7, which was not found in my registry. I ran regedit and searched
for Pytho
actions:
- start benchmarking numpy import in a per-commit manner to detect
significant regressions (like what happens with polynomial code)
- have a small FAQ on it, with suggestion for people who need to
optimize their short-lived script
cheers,
David
On Tue, Jul 17, 2012 at 1:13 PM, Charles R Harris
wrote:
>
>
> On Tue, Jul 17, 2012 at 1:31 AM, David Cournapeau
> wrote:
>>
>> On Mon, Jul 16, 2012 at 5:28 PM, Charles R Harris
>> wrote:
>> > Hi All,
>> >
>> > Working lazy imports
drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll:
>> PE32 executable for MS Windows (DLL) (unknown subsystem) Intel 80386
>> 32-bit
>>
>>
>> But objdump doesn't work on it.
>
> So the following patch fix
On Wed, Jul 18, 2012 at 3:17 PM, Travis Oliphant wrote:
> I don't have a strong preference. Which one do others prefer?
>
We've used 2) in the past, and I don't think Ralf changed this when he
took over release maintenance.
David
time to
look into it in the next few hours. You got the issue for Mingw 3.x,
right ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
lding numpy and testing mostly work for me (tried the
last commit from 1.7.x branch) with mingw 5.0.4 with python 2.7.3 and
*without* any change in the code (i.e. I did not commented out the
part to build msgcr90 import library).
- I don't know what the issue is in your environment for msvc90, but
I can confirm that it is required. gcc 3.x which was built around
2005/2006 cannot possibly provide the import library for msvcr90, and
the build works ok
- I strongly suspect some issues because you started with mingw /
gcc 4.x. If you moved some libraries in system directories, I suggest
you start fresh from a clean state in your VM (or rm -rf .wine :) ).
I noticed that when VS 2008 is available, distutils does the
configuration with MS compilers, which is broken. I will test later on
a machine wo vs 2008.
cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
7;s your problem right there. You should not need to do
that, and doing so will likely result in having multiple copies of the
DLL in your process (you can confirm with process dependency walker).
This should be avoided at all cost, as the python C API is not
designed to deal with this, and your crash
1.7, I would suggest passing this to the
next release, unless the fix is simple (just a change of API).
cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau wrote:
> On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant wrote:
>> Hey all,
>>
>> I'm wondering who has tried to make NumPy work with Python 3.3. The
>> Unicode handling was significantly improved in Python 3
x27;d like to wrap:
>
> void FOO::fooNumpy(PyArrayObject *nparray) {
>
> int j;
> for(j=0;jnd;j++) {
> printf("Ok array dim %i has length: %i\n",j,nparray->dimensions[j]);
> }
> }
I never do it with Swig, will try to make this example
> > I'm looking at SWIG/numpy tutorials
> They are these tutorials:
> http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html
> http://www.scipy.org/Cookbook/SWIG_NumPy_examples
Sorry, I've read "look for"...
___
NumPy-Discussion mailing list
N
t DIM1) {(int* rangevec, int n)}
> >it will apply on every functions that have arguments "int* ARGOUT_ARRAY1,
> >int DIM1"
On Tue, 31 Jul 2012 15:28:02 -0700, "Doutriaux, Charles"
wrote:
> Thanks David,
>
> The clarification on apply is actually a important
On Tue, 31 Jul 2012 14:48:24 -0600, "Bill Spotz" wrote:
> Use %inline %{ ... %} around your function. SWIG will add your function
> directly to the wrapper file as well as add a wrapper function for calling it
> from python.
>
> On Jul 31, 2012, at 2:04 PM, Davi
think about giving up on accelerate, and use e.g. ATLAS on mac
for our official binaries.
Long story: we recently received a answer where the engineers mention
that using blas on each 'side' of a fork is not supported. The meat of
the email is attached below
thoughts ?
David
--
On Sat, Aug 4, 2012 at 12:14 PM, Aron Ahmadia wrote:
> Hi David,
>
> Apple's response here is somewhat confusing, but I will add that on the
> supercomputing side of things we rarely fork, as this is not well-supported
> from the vendors or the hardware (it's hard eno
-1;
>> > case '>':
>> > byteorder = 1;
>> > default: /* '=', '|' */
>> > byteorder = 0;
>> > }
>>
>> I think you might want some breaks in here...
>
> Indeed.
packages
>
> This should not present a problem and does not explain why numpy does not
> build/import correctly on my setup.
Please give us the build log (when rebuilding from scratch to have the
complete log) so that we can have a better idea of the issue,
David
eal' solution is to have a separate package linking to
FFTW for people with 'advanced' needs for FFT. None of the other
library I have looked at so far are usable, fast and precise enough
when you go far from the simple case of double precision and 'well
factored' size.
rega
On Wed, Aug 8, 2012 at 10:53 AM, Robert Kern wrote:
> On Wed, Aug 8, 2012 at 10:34 AM, David Cournapeau wrote:
>> On Wed, Aug 8, 2012 at 12:55 AM, Nathaniel Smith wrote:
>>> On Mon, Aug 6, 2012 at 8:31 PM, Robert Kern wrote:
>>>> Those are not the original Fortran
t is the way to go. I myself have
some stuff for native windows and vagrant (much more painful, but
sometimes necessary unfortunately).
Did you see veewee to create vagrant boxes ? It simplifies quite a few
things, but maybe they matter more on windo
han happy to have a
suggestion for a better way because uploading on sourceforge is the
very definition of pain).
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Aug 14, 2012 at 11:22 AM, Nathaniel Smith wrote:
> On Tue, Aug 14, 2012 at 11:06 AM, David Cournapeau wrote:
>> Hi Ondrej,
>>
>> On Tue, Aug 14, 2012 at 5:34 AM, Ondřej Čertík
>> wrote:
>>> Hi,
>>>
>>> How should one use the "
n (in which case I
get an expected invalid cast exception). Is there a way to still avoid
those casts while keeping the 'f' kind ?
thanks,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
an
compiler is not enough because it makes it difficult for people to
build on top of scipy.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Aug 22, 2012 at 12:17 PM, Peter
wrote:
> On Wed, Aug 22, 2012 at 11:40 AM, David Cournapeau wrote:
>> On Tue, Aug 21, 2012 at 12:15 AM, Chris Barker wrote:
>>> On Mon, Aug 20, 2012 at 3:51 PM, Travis Oliphant
>>> wrote:
>>>> I'm actually
On Wed, Aug 22, 2012 at 3:14 PM, Nathaniel Smith wrote:
> On Wed, Aug 22, 2012 at 11:40 AM, David Cournapeau wrote:
>> On Tue, Aug 21, 2012 at 12:15 AM, Chris Barker wrote:
>>> On Mon, Aug 20, 2012 at 3:51 PM, Travis Oliphant
>>> wrote:
>>>> I'm ac
pervasive than that, unfortunately. And for fortran,
it is much worse, because if we build scipy or numpy with Intel
Fortran, I think we pretty much force everyone to use intel fortran
for *any* binary on top of them.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Aug 22, 2012 at 3:35 PM, Travis Oliphant wrote:
> On Aug 22, 2012, at 9:28 AM, David Cournapeau wrote:
>
>> On Wed, Aug 22, 2012 at 3:25 PM, Travis Oliphant wrote:
>>>
>>> On Aug 22, 2012, at 3:59 AM, Ralf Gommers wrote:
>>>
>>>
>>&
On Wed, Aug 22, 2012 at 4:12 PM, Ondřej Čertík wrote:
> On Wed, Aug 22, 2012 at 7:35 AM, Travis Oliphant wrote:
>> On Aug 22, 2012, at 9:28 AM, David Cournapeau wrote:
>>
>>> On Wed, Aug 22, 2012 at 3:25 PM, Travis Oliphant
>>> wrote:
>>>>
>>
On Wed, Aug 22, 2012 at 5:46 PM, Ondřej Čertík wrote:
> On Wed, Aug 22, 2012 at 8:50 AM, David Cournapeau wrote:
>> On Wed, Aug 22, 2012 at 4:12 PM, Ondřej Čertík
>> wrote:
>>> On Wed, Aug 22, 2012 at 7:35 AM, Travis Oliphant
>>> wrote:
>>>>
n to not work with scipy. It may a
bug in gcc-llvm (or, more unlikely, in scipy). I recommend you use the
binaries with the python from python.org website, or to use clang to
build it on lion.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@sci
ssues: do you have any concrete measurements (or
usecases) where this is problematic ?
- updating the refcount: can you give an example ?
thanks,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
s building.
> (OSX lion 10.7.4 /Xcode 4.5 /clang /gfortran4.2.3)
Those error are parts of the configuration. As long as the build runs
until the end, the build is successful. You should not build scipy
with gcc on mac os x 10.7, as it is known to cause issues.
David
___
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Ok, so since many people asked: this was sent by mistake, and intended
to be a discarded draft instead.
David
On Tue, Sep 25, 2012 at 7:13 PM, Ralf Gommers wrote:
> is a good thing:)
>
>
>
>
> On Tue, Sep 25, 2012 at 2:06 PM, David C
nough
>> > along that we have agreed on workflow and labels to use.
>>
>> My concern is that transitioning first would define the
>> workflow/labels based on what's in Trac, rather than on what would
>> work best with github.
>
>
> Trac is not unique, most bug trackers have similar concepts (milestones,
> components, prios, issue types).
>
>>
>> But maybe the best way to move things forward
>> is to do the transition to a test project, and see what comes out.
Ok, so scipy.org was down again because of trac. Unfortunately, the
machine on which scipy.org lives is the same as trac, and is a bit
messy. I would really like to accelerate whatever needs to be done to
get that done, both to get out of trac's misery, and to make scipy.org
more responsive.
I can't promise a lot of spare cycles, but I will make sure there are
no roadblocks on Enthought side when we need to make the actual
migration.
Thouis, what needs to be done to make a testbed of the conversion ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ation) and src/umath contains the
code for the umath extension (ufunc machinery + core loops
implementation).
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ny.
>
> It's probably a good idea to turn off Trac, soon, to keep too many new
> bugs from needing to be ported, and old bugs being commented on. The
> latter is more of a pain to deal with.
I will look into making the NumPy trac read-only. It should not be too
complicated to extend Pauli's code to redirect the tickets part to
github issues.
Have we decided what to do with the wiki content ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Oct 23, 2012 at 8:57 PM, Thouis (Ray) Jones wrote:
> On Tue, Oct 23, 2012 at 10:58 AM, David Cournapeau wrote:
>> I will look into making the NumPy trac read-only. It should not be too
>> complicated to extend Pauli's code to redirect the tickets part to
>> gith
On Sat, Oct 27, 2012 at 4:06 AM, Jack Bryan wrote:
> Thanks for your help.
>
> Why do the Anaconda and EPD can help me fix the problem ?
Because they are an all-included distribution of python with
numpy/scipy and many other packages. You don't need to compile
an
ion, because those
libraries are rarely if ever ABI compatible (that's why it is such a
pain to support).
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Nov 7, 2012 at 1:56 PM, Neal Becker wrote:
> David Cournapeau wrote:
>
>> On Wed, Nov 7, 2012 at 12:35 PM, Neal Becker wrote:
>>> I'm trying to do a bit of benchmarking to see if amd libm/acml will help me.
>>>
>>> I got an idea that instead
e this (provided the output order issue is fixed), and it doesn't make
> sense to not have old codes take advantage of the speed improvement.
Indeed, there is no reason not to make this available in NumPy.
Nicolas, can you prepare a patch for numpy ?
David
inal release of
>> 1.7.0 to just after Thanksgiving.
>
>
>
> I successfully defended my Ph.D. thesis last Thursday, I just need to
> do some changes to it and submit it and I am done.
Congrats, (almost) Dr. Čertík :)
cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
s still outperform
> at least Intel MKL, because MKL does so poorly on these -- although ACML
> beats them both by a factor 2. And of course on supported CPUs
> (everything Intel and older AMD) OpenBLAS is wonderful.
I support this as well in principle for our binary release: one issue
is that
On Tue, Nov 20, 2012 at 5:03 PM, Sturla Molden wrote:
> On 20.11.2012 15:38, David Cournapeau wrote:
>
>> I support this as well in principle for our binary release: one issue
>> is that we don't have the infrastructure on mac to build an installer
>> with multi-arch
401 - 500 of 3277 matches
Mail list logo
