Next | Query returned 107 messages, browsing 1 to 10 | Previous

History of commit frequency

CVS Commit History:


   2021-11-06 12:52:37 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-numpy: updated to 1.21.4

The NumPy 1.21.4 is a maintenance release that fixes a few bugs
discovered after 1.21.3. The most important fix here is a fix for the
NumPy header files to make them work for both x86_64 and M1 hardware
when included in the Mac universal2 wheels. Previously, the header files
only worked for M1 and this caused problems for folks building x86_64
extensions. This problem was not seen before Python 3.10 because there
were thin wheels for x86_64 that had precedence. This release also
provides thin x86_64 Mac wheels for Python 3.10.
   2021-11-02 19:48:28 by Adam Ciarcinski | Files touched by this commit (4) | Package updated
Log message:
py-numpy: updated to 1.21.3

1.21.0

New functions

Add PCG64DXSM BitGenerator

Deprecations

The .dtype attribute must return a dtype
Inexact matches for numpy.convolve and numpy.correlate are deprecated
np.typeDict has been formally deprecated
Exceptions will be raised during array-like creation
Four ndarray.ctypes methods have been deprecated

Expired deprecations

Remove deprecated PolyBase and unused PolyError and PolyDomainError

Compatibility notes

Error type changes in universal functions
__array_ufunc__ argument validation
__array_ufunc__ and additional positional arguments
Validate input values in Generator.uniform
/usr/include removed from default include paths
Changes to comparisons with dtype=...
Changes to dtype and signature arguments in ufuncs
Ufunc signature=... and dtype= generalization and casting
Distutils forces strict floating point model on clang

C API changes

Use of ufunc->type_resolver and “type tuple”

New Features

Added a mypy plugin for handling platform-specific numpy.number precisions
Let the mypy plugin manage extended-precision numpy.number subclasses
New min_digits argument for printing float values
f2py now recognizes Fortran abstract interface blocks
BLAS and LAPACK configuration via environment variables
A runtime-subcriptable alias has been added for ndarray

Improvements

Arbitrary period option for numpy.unwrap
np.unique now returns single NaN
Generator.rayleigh and Generator.geometric performance improved
Placeholder annotations have been improved
Performance improvements
Improved performance in integer division of NumPy arrays
Improve performance of np.save and np.load for small arrays

Changes

numpy.piecewise output class now matches the input class
Enable Accelerate Framework
   2021-10-26 12:56:13 by Nia Alarie | Files touched by this commit (458)
Log message:
math: Replace RMD160 checksums with BLAKE2s checksums

All checksums have been double-checked against existing RMD160 and
SHA512 hashes
   2021-10-07 16:28:36 by Nia Alarie | Files touched by this commit (458)
Log message:
math: Remove SHA1 hashes for distfiles
   2021-07-01 08:13:45 by Nia Alarie | Files touched by this commit (1)
Log message:
py-numpy: set PYTHON_VERSIONS_INCOMPATIBLE in bl3.mk
   2021-06-29 10:42:02 by Nia Alarie | Files touched by this commit (28)
Log message:
py-numpy: "Python version >= 3.7 required."
   2021-06-15 06:41:53 by Dr. Thomas Orgis | Files touched by this commit (36)
Log message:
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits

This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.

In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).

The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.

There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).

Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.

Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that

This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
   2021-06-15 03:43:44 by Dr. Thomas Orgis | Files touched by this commit (2)
Log message:
math/py-numpy: document BLAS distinfo patch
   2021-05-12 10:12:10 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-numpy: updated to 1.20.3

1.20.3:
BUG: Correct ``datetime64`` missing type overload for ``datetime.date``
MAINT: Remove ``__all__`` in favor of explicit re-exports
BLD: Strip extra newline when dumping gfortran version on MacOS
BUG: fix segfault in object/longdouble operations
MAINT: Use towncrier build explicitly
MAINT: Relax certain integer-type constraints
MAINT: Remove unsafe unions and ABCs from return-annotations
MAINT: Allow more recursion depth for scalar tests.
BUG: Initialize the full nditer buffer in case of error
BLD: remove unnecessary flag ``-faltivec`` on macOS
MAINT, CI: treats _SIMD module build warnings as errors through...
BUG: for MINGW, threads.h existence test requires GLIBC > 2.12
BUG: Make changelog recognize gh- as a PR number prefix.
REL, DOC: Prepare for the NumPy 1.20.3 release.
BUG: Fix failing mypy test in 1.20.x.
   2021-05-05 08:27:45 by Thomas Klausner | Files touched by this commit (1)
Log message:
py-numpy: allow python 3.6 again

Better have this listed as breakage for py36-numpy than not having the
bulk builds start up because the packages using this still want to
build it for python 3.6

Next | Query returned 107 messages, browsing 1 to 10 | Previous