Hi,
I will add a a wiki page ASAP.
BTW: I copied my tools (gcc toolchain, numpy, scipy wheels) from my google
drive to bitbucket:
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads
Regards
Carl
2014-04-04 21:56 GMT+02:00 Matthew Brett :
> Hi,
>
> On Fri, Apr 4, 2014 at 8:19 AM, Carl
Hi,
On Fri, Apr 4, 2014 at 8:19 AM, Carl Kleffner wrote:
>
> I'ts time for me to come back to the discussion after a longer break.
>
> some personal history: I was looking for a 64bit mingw more than a year ago
> (unrelated to python) for Fortran development and tried out quite some mingw
> toolc
I'ts time for me to come back to the discussion after a longer break.
some personal history: I was looking for a 64bit mingw more than a year ago
(unrelated to python) for Fortran development and tried out quite some
mingw toolchain variants based on the mingw-w64 project. In a nutshell: the
most
I'ts time for me to come back to the discussion after a longer break.
some personal history: I was looking for a 64bit mingw more than a year ago
(unrelated to python) for Fortran development and tried out quite some
mingw toolchain variants based on the mingw-w64 project. In a nutshell: the
most
On Wed, Apr 2, 2014 at 7:52 AM, Matthew Brett wrote:
> Hi,
>
> On Tue, Apr 1, 2014 at 4:46 PM, David Cournapeau
> wrote:
> >
> >
> >
> > On Wed, Apr 2, 2014 at 12:36 AM, Nathaniel Smith wrote:
> >>
> >> On Tue, Apr 1, 2014 at 11:58 PM, David Cournapeau
> >> wrote:
> >> > On Tue, Apr 1, 2014 at
On Apr 1, 2014, at 4:36 PM, Nathaniel Smith wrote:
> We could just ship all numpy's extension modules in the same directory
> if we wanted. It would be pretty easy to stick some code at the top of
> numpy/__init__.py to load them from numpy/all_dlls/ and then slot them
> into the appropriate plac
Hi,
On Tue, Apr 1, 2014 at 4:46 PM, David Cournapeau wrote:
>
>
>
> On Wed, Apr 2, 2014 at 12:36 AM, Nathaniel Smith wrote:
>>
>> On Tue, Apr 1, 2014 at 11:58 PM, David Cournapeau
>> wrote:
>> > On Tue, Apr 1, 2014 at 6:43 PM, Nathaniel Smith wrote:
>> >>
>> >> On Tue, Apr 1, 2014 at 6:26 PM,
On Wed, Apr 2, 2014 at 12:36 AM, Nathaniel Smith wrote:
> On Tue, Apr 1, 2014 at 11:58 PM, David Cournapeau
> wrote:
> > On Tue, Apr 1, 2014 at 6:43 PM, Nathaniel Smith wrote:
> >>
> >> On Tue, Apr 1, 2014 at 6:26 PM, Matthew Brett
> >> wrote:
> >> > I'm guessing that the LOAD_WITH_ALTERED_SEA
On Tue, Apr 1, 2014 at 11:58 PM, David Cournapeau wrote:
> On Tue, Apr 1, 2014 at 6:43 PM, Nathaniel Smith wrote:
>>
>> On Tue, Apr 1, 2014 at 6:26 PM, Matthew Brett
>> wrote:
>> > I'm guessing that the LOAD_WITH_ALTERED_SEARCH_PATH means that a DLL
>> > loaded via:
>> >
>> > hDLL = LoadLibraryE
On Tue, Apr 1, 2014 at 6:43 PM, Nathaniel Smith wrote:
> On Tue, Apr 1, 2014 at 6:26 PM, Matthew Brett
> wrote:
> > I'm guessing that the LOAD_WITH_ALTERED_SEARCH_PATH means that a DLL
> loaded via:
> >
> > hDLL = LoadLibraryEx(pathname, NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
> >
> > will in tur
Hi,
I just noticed this C reference implementation of blas:
https://github.com/rljames/coblas
No lapack, no benchmarks, but tests, and BSD. I wonder if it is
possible to craft a Frankenlibrary from OpenBLAS and reference
implementations to avoid broken parts of OpenBLAS?
Cheers,
Matthew
_
Hi,
On Tue, Apr 1, 2014 at 10:43 AM, Nathaniel Smith wrote:
> On Tue, Apr 1, 2014 at 6:26 PM, Matthew Brett wrote:
>> I'm guessing that the LOAD_WITH_ALTERED_SEARCH_PATH means that a DLL loaded
>> via:
>>
>> hDLL = LoadLibraryEx(pathname, NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
>>
>> will in tur
On Tue, Apr 1, 2014 at 6:26 PM, Matthew Brett wrote:
> I'm guessing that the LOAD_WITH_ALTERED_SEARCH_PATH means that a DLL loaded
> via:
>
> hDLL = LoadLibraryEx(pathname, NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
>
> will in turn (by default) search for its dependent DLLs in their own
> directory.
Hi,
On Tue, Apr 1, 2014 at 9:04 AM, Chris Barker wrote:
> On Mon, Mar 31, 2014 at 3:09 PM, Matthew Brett
> wrote:
>>
>> I am hopelessly lost here, but it looks as though Python extension
>> modules get loaded via
>>
>> hDLL = LoadLibraryEx(pathname, NULL,
>> LOAD
On Mon, Mar 31, 2014 at 3:09 PM, Matthew Brett wrote:
> I am hopelessly lost here, but it looks as though Python extension
> modules get loaded via
>
> hDLL = LoadLibraryEx(pathname, NULL,
> LOAD_WITH_ALTERED_SEARCH_PATH);
>
> See:
> http://hg.python.org/cpython/fi
Hi,
On Mon, Mar 31, 2014 at 12:27 PM, Chris Barker wrote:
> On Mon, Mar 31, 2014 at 12:05 PM, Matthew Brett
> wrote:
>>
>> > that part, yes, but isn't Linux too much of a varying target for there
>> > to be
>> > any point anyway?
>>
>> You mean, the /usr/lib stuff varies too much, so that any co
On Mon, Mar 31, 2014 at 12:05 PM, Matthew Brett wrote:
> > that part, yes, but isn't Linux too much of a varying target for there
> to be
> > any point anyway?
>
> You mean, the /usr/lib stuff varies too much, so that any copied
> dynamic libraries would have little chance of binary compatibility
Hi,
On Mon, Mar 31, 2014 at 11:55 AM, Chris Barker wrote:
> On Mon, Mar 31, 2014 at 10:18 AM, Matthew Brett
> wrote:
>>
>> > Bonus question: do you think a similar solution could work for windows
>> > and / or linux?
>>
>> For linux - yes - I think that should be easy with a combination of
>> ``
On Mon, Mar 31, 2014 at 10:18 AM, Matthew Brett wrote:
> > Bonus question: do you think a similar solution could work for windows
> > and / or linux?
>
> For linux - yes - I think that should be easy with a combination of
> ``ldd`` to find the dependencies and ``patchelf`` to set the rpath to
> po
Hi,
On Mon, Mar 31, 2014 at 4:53 AM, Olivier Grisel
wrote:
> 2014-03-28 23:13 GMT+01:00 Matthew Brett :
>> Hi,
>>
>> On Fri, Mar 28, 2014 at 3:09 PM, Olivier Grisel
>> wrote:
>>> This is great! Has anyone started to work on OSX whl packages for
>>> scipy? I assume the libgfortran, libquadmath &
On Mon, Mar 31, 2014 at 6:30 PM, Matthew Brett wrote:
> Hi,
>
> On Mon, Mar 31, 2014 at 5:17 AM, Olivier Grisel
> wrote:
> > 2014-03-31 13:53 GMT+02:00 Olivier Grisel :
> >> 2014-03-28 23:13 GMT+01:00 Matthew Brett :
> >>> Hi,
> >>>
> >>> On Fri, Mar 28, 2014 at 3:09 PM, Olivier Grisel
> >>> wro
Hi,
On Mon, Mar 31, 2014 at 5:17 AM, Olivier Grisel
wrote:
> 2014-03-31 13:53 GMT+02:00 Olivier Grisel :
>> 2014-03-28 23:13 GMT+01:00 Matthew Brett :
>>> Hi,
>>>
>>> On Fri, Mar 28, 2014 at 3:09 PM, Olivier Grisel
>>> wrote:
This is great! Has anyone started to work on OSX whl packages for
2014-03-31 13:53 GMT+02:00 Olivier Grisel :
> 2014-03-28 23:13 GMT+01:00 Matthew Brett :
>> Hi,
>>
>> On Fri, Mar 28, 2014 at 3:09 PM, Olivier Grisel
>> wrote:
>>> This is great! Has anyone started to work on OSX whl packages for
>>> scipy? I assume the libgfortran, libquadmath & libgcc_s dylibs w
2014-03-28 23:13 GMT+01:00 Matthew Brett :
> Hi,
>
> On Fri, Mar 28, 2014 at 3:09 PM, Olivier Grisel
> wrote:
>> This is great! Has anyone started to work on OSX whl packages for
>> scipy? I assume the libgfortran, libquadmath & libgcc_s dylibs will
>> not make it as easy as for numpy. Would it be
Hi,
On Fri, Mar 28, 2014 at 3:09 PM, Olivier Grisel
wrote:
> This is great! Has anyone started to work on OSX whl packages for
> scipy? I assume the libgfortran, libquadmath & libgcc_s dylibs will
> not make it as easy as for numpy. Would it be possible to use a static
> gcc toolchain as Carl Kle
On 28.03.2014 23:09, Olivier Grisel wrote:
> This is great! Has anyone started to work on OSX whl packages for
> scipy? I assume the libgfortran, libquadmath & libgcc_s dylibs will
> not make it as easy as for numpy. Would it be possible to use a static
> gcc toolchain as Carl Kleffner is using for
This is great! Has anyone started to work on OSX whl packages for
scipy? I assume the libgfortran, libquadmath & libgcc_s dylibs will
not make it as easy as for numpy. Would it be possible to use a static
gcc toolchain as Carl Kleffner is using for his experimental windows
whl packages?
--
Olivie
Hi,
On Wed, Mar 26, 2014 at 3:02 PM, Chris Barker wrote:
> On Wed, Mar 26, 2014 at 8:56 AM, Charles R Harris
> wrote:
>>
>>
>>> 5 seconds waiting on a home internet connection and a numpy install
>>> Nice.
>>>
>>
>> That's pretty neat. Now if we can get the windows versions to be as easy.
>>
On Wed, Mar 26, 2014 at 8:56 AM, Charles R Harris wrote:
>
> 5 seconds waiting on a home internet connection and a numpy install
>> Nice.
>>
>>
> That's pretty neat. Now if we can get the windows versions to be as easy.
>
>
Indeed -- where are we on that? Wasn't there more or less a consensu
On Tue, Mar 25, 2014 at 9:47 PM, Matthew Brett wrote:
> Hi,
>
> On Tue, Mar 25, 2014 at 4:38 PM, Julian Taylor
> wrote:
> > Hello,
> >
> > I'm happy to announce the of Numpy 1.8.1.
> > This is a bugfix only release supporting Python 2.6 - 2.7 and 3.2 - 3.4.
> >
> > More than 48 issues have been f
Hi,
On Tue, Mar 25, 2014 at 4:38 PM, Julian Taylor
wrote:
> Hello,
>
> I'm happy to announce the of Numpy 1.8.1.
> This is a bugfix only release supporting Python 2.6 - 2.7 and 3.2 - 3.4.
>
> More than 48 issues have been fixed, the most important issues are
> listed in the release notes:
> https
Hello,
I'm happy to announce the of Numpy 1.8.1.
This is a bugfix only release supporting Python 2.6 - 2.7 and 3.2 - 3.4.
More than 48 issues have been fixed, the most important issues are
listed in the release notes:
https://github.com/numpy/numpy/blob/maintenance/1.8.x/doc/release/1.8.1-notes.r
32 matches
Mail list logo
