Install the new interchangeable BLAS system created by Thomas Orgis,
currently supporting Netlib BLAS/LAPACK, OpenBLAS, cblas, lapacke, and
Apple's Accelerate.framework. This system allows the user to select any
BLAS implementation without modifying packages or using package options, by
setting PKGSRC_BLAS_TYPES in mk.conf. See mk/blas.buildlink3.mk for details.
This commit should not alter behavior of existing packages as the system
defaults to Netlib BLAS/LAPACK, which until now has been the only supported
implementation.
Details:
Add new mk/blas.buildlink3.mk for inclusion in dependent packages
Install compatible Netlib math/blas and math/lapack packages
Update math/blas and math/lapack MAINTAINER approved by adam@
OpenBLAS, cblas, and lapacke will follow in separate commits
Update direct dependents to use mk/blas.buildlink3.mk
Perform recursive revbump
PLIST was wrong due to build system using python's sys.platorm, which the
package Makefile incorrectly tried to replicate using pkgsrc variables.
Also added LICENSE and fixed one undocumented patch.
2.8 --> 2.8.1
-------------
Improvements:
- The installation procedure was updated to work with recent
NumPy versions and in a wider range of environments.
either because they themselves are not ready or because a
dependency isn't. This is annotated by
PYTHON_VERSIONS_INCOMPATIBLE= 33 # not yet ported as of x.y.z
or
PYTHON_VERSIONS_INCOMPATIBLE= 33 # py-foo, py-bar
respectively, please use the same style for other packages,
and check during updates.
Use versioned_dependencies.mk where applicable.
Use REPLACE_PYTHON instead of handcoded alternatives, where applicable.
Reorder Makefile sections into standard order, where applicable.
Remove PYTHON_VERSIONS_INCLUDE_3X lines since that will be default
with the next commit.
Whitespace cleanups and other nits corrected, where necessary.
Based on PR#43282 by Wen Heping.
2.7.9 --> 2.7.10
----------------
Bug fixes:
- Removed all occurrences of "as" as a variable name for compatibility
with Python 2.6.
- Installation without the netCDF module did not work.
Improvements:
- Vector.dyadicProduct() was replaced by a more efficient implementation.
- Scientific.IO.PDB: Atom objects now have a parent attribute whose
value is the containing group.
2.7.8 --> 2.7.9
---------------
License change: ScientificPython is now distributed under the
CeCILL-C license, which is an adaptation of the LGPL to French
law. The previously used CeCILL license, similar to the GPL, was
considered too restrictive.
Bug fixes:
- MPI interfaces did not work correctly with NumPy and/or Python 2.5.
Improvements:
- Compilation script for mpipython works around a Python configuration
bug under MacOS X.
- Docstrings have been cleaned up.
2.7.7 --> 2.7.8
---------------
Bug fixes:
- Due to a typo in Scientific.IO.PDBSpaceGroups, some space group
names were not found in the space group table.
Improvements:
- Vector objects can now be multiplied with NumPy scalar objects
(which is what you get when extracting numbers from NumPy
arrays). Due to the way NumPy scalars handle multiplication, the
result used to be an array rather than a Vector, which caused
various applications to crash.
- The build procedure under Windows has been improved. It can
generate a binary installer that includes the netCDF DLL,
making ScientificPython independent of a netCDF installation.
2.7.6 --> 2.7.7
---------------
Bug fixes:
- Installation on Windows didn't work because the Unix maths libraries
don't exist there.
Improvements:
- InterpolatingFunction and TensorField objects can represent
periodic functions/fields.
- DistributedComputing: the watchdog period of slave processes is now
a user-definable parameter.
- PDBSpaceGroups was simplified, making it shorter and faster to load.
- Scientific.N contains the array type object in the variable array_type.
This makes it possible to write Pyrex modules using arrays in such a
way that they always use the numeric module for which ScientificPython
was compiled.
2.7.5 --> 2.7.6
---------------
Bug fixes:
- NumPy compatibility fixes.
- Pyro 3.6 compatibility fix in DistributedComputing.MasterSlave
2.7.4 --> 2.7.5
---------------
New features:
- Scaling, inversion, and shear transformations added to
Geometry.Transformations
Improvements:
- PDB parser handles CRYST1, SCALEn and MTRIXn records
- Better identification of the Numerics package that is being used
Bug fixes:
- Scientific_affinitypropagation.c compiles with NumPy
2.7.3 --> 2.7.4
---------------
New features:
- New module Clustering.AffinityPropagation.
- New class BSP.ParRootSequence.
Bug fixes:
- Replaced float equality test in Functions.InterpolatingFunction
- Removed exception for order > 1 in Derivatives.DerivVar.__init__
- Fixed reading of non-string attributes from netCDF files.
Improvements:
- New methods getBinIndices and getBinCount in Statistics.Histogram.Histogram
- Physics.PhysicalQuantities: unit definitions added to doc string
2.7.2 --> 2.7.3
---------------
Improvements:
- Added multi-module setup for master-slave computations.
- More information available through task_manager.
- task_manager can start slave processes.
2.7.1 --> 2.7.2
---------------
Bug fixes:
- Scientific_netcdf would not compile with NumPy under Python 2.4
because NumPy also defined Py_ssize_t.
2.7 --> 2.7.1
-------------
Improvements:
- NumPy compatibility. Scientific_netcdf was revised by hand.
The Python code was run through numpy.oldnumeric.alter_code1 to
identify the critical sections, which were then all handled in
some way. It is possible that there are still incompatibilities
of the kind that numpy.oldnumeric.alter_code1 cannot detect
2.5.12hg --> 2.7
----------------
New features:
- Subpackage Scientific.DistributedComputing for easy parallelization
of independent tasks.
2.5.11 --> 2.5.12hg
-------------------
Bug fixes:
- VRML2 output would crash for scenes containing Line objects
- Pyrex implmentation of vector objects could crash instead of raising
an exception in divide operations.
- Pyrex implmentation of vector objects would raise exceptions incorrectly
under Python 2.5
Improvements:
- builds Macintosh packages with documentation and examples
2.5.10 --> 2.5.11
-----------------
Bug fixes:
- Pyrex implementation of vector objects raised exceptions in comparisons
- Pyrex implementation of vector objects did not accept negative indices
- Some object deletions during conversion to epydoc had to be reversed
Improvements:
- Two test suites
2.5.9 --> 2.5.10
----------------
Bug fixes:
- Fixed netCDF error handling
Improvements:
- Support for NumPy (not very well tested yet)
- Scientific.NumberDict more efficient
2.5.8 --> 2.5.9
---------------
Improvements:
- Scientifc.IO.NetCDF supports the new 64-bit data structures in Python 2.5
(not yet tested on a 64-bit machine)
- Docstrings modified for use with Epydoc.
2.5.7 --> 2.5.8
---------------
Bug fixes:
- Syntax error in Scientific.IO.PDB
- Attribute deletion in netCDF file and variable objects caused a crash.
2.5.6 --> 2.5.7
----------------
Bug fixes:
- Tensor-vector multiplication was incorrect with the Pyrex implementation
of vector objects.
2.5.5 --> 2.5.6
----------------
Bug fixes:
- Scientific.BSP.ParClass did not pass on __call__ and __getitem__
to local class
- Scientific.BSP.ParClass: Class wrappers did not always return the right
global object.
2.5.4 --> 2.5.5
----------------
Bug fixes:
- Scientific.IO.NetCDF.NetCDFVariable.assignValue() had incomplete error
reporting. Some errors would not raise exceptions as required.
2.5.3 --> 2.5.4
----------------
Improvements:
- A "test" method on MPI request objects permits to check if data
is available (thanks to Jakob Schiotz for this addition).
Bug fixes:
- The new Pyrex vector objects could not be pickled.
2.5.1 --> 2.5.3
----------------
Improvements:
- The class Scientific.Geometry.Vector has been reimplemented in Pyrex,
yielding much faster vector operations. There is, however, the restriction
that the vector elements must be of type "float". For the rare applications
where this condition is not fulfilled (such as
Scientific.Functions.Derivatives.DerivVector), the Python implementation
remains accessible as Scientific.Geometry.VectorModule.Vector.
2.4.9 --> 2.5.1
----------------
Improvements:
- Vector and Tensor objects permit comparison with other types
of objects (which always return False)
- Numarray can be used instead of Numeric as far as possible
(see README for details)
2.4.7 --> 2.4.9:
----------------
Bug fixes:
- Integer array attributes caused a TypeError with recent versions of
Numeric (that don't do silent casts from Long to Int any more).
Additions:
- Method "threeAngles" in Geometry.Transformation.Rotation.
2.4.6 --> 2.4.7:
----------------
Bug fixes:
- Scientific.BSP: alltrue() and anytrue() sometimes returned wrong results.
Additions:
- Scientific.Visualization.VMD can now correctly launch VMD under Windows
on some platforms that lacked shared library support in the past. The
list hasn't been maintained at all and the gain is very limited, so just
get rid of it.
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.
RECOMMENDED is removed. It becomes ABI_DEPENDS.
BUILDLINK_RECOMMENDED.foo becomes BUILDLINK_ABI_DEPENDS.foo.
BUILDLINK_DEPENDS.foo becomes BUILDLINK_API_DEPENDS.foo.
BUILDLINK_DEPENDS does not change.
IGNORE_RECOMMENDED (which defaulted to "no") becomes USE_ABI_DEPENDS
which defaults to "yes".
Added to obsolete.mk checking for IGNORE_RECOMMENDED.
I did not manually go through and fix any aesthetic tab/spacing issues.
I have tested the above patch on DragonFly building and packaging
subversion and pkglint and their many dependencies.
I have also tested USE_ABI_DEPENDS=no on my NetBSD workstation (where I
have used IGNORE_RECOMMENDED for a long time). I have been an active user
of IGNORE_RECOMMENDED since it was available.
As suggested, I removed the documentation sentences suggesting bumping for
"security" issues.
As discussed on tech-pkg.
I will commit to revbump, pkglint, pkg_install, createbuildlink separately.
Note that if you use wip, it will fail! I will commit to pkgsrc-wip
later (within day).
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
