DEBUG: wheel build debugging #77
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Fixes scipygh-20300 by syncing `pocketfft` again, this time to completely disable `aligned_alloc`; see scipy/pocketfft#3 for details, but in short our more conservative shim was not sufficient for `conda-forge`, so let's just do the same thing NumPy did... [skip cirrus] [skip circle]
This was reported to cause test failures under windows + MKL in conda-forge cf scipy#20471
A slight tolerance violation was reported on conda-forge in scipy#20472
A small tolerance violation reported on conda-forge in scipy#20472
An exact equality was reported as flaky on conda-forge in scipy#20472 The tolerance violations are of the order of fp noise (< 2e-16), and I don't think that pickling/unpickling guarantees bit-to-bit compatibility. In principle, this may invoke recalculations and those may be subject to fp noise. So I think it's OK to only require allclose(atol=eps) instead of exact equality.
tol violation observed on conda-forge on win+blis; suggested in scipy#20474 (comment)
f2py check was just too strict; LAPACK docs indicate that for N=1, lwork>=1 is acceptable: * LWORK (input) INTEGER * The dimension of the array WORK. * If N <= 1, LWORK must be at least 1. * If JOBZ = 'N' and N > 1, LWORK must be at least 2*N+1. * If JOBZ = 'V' and N > 1, LWORK must be at least * 1 + 6*N + 2*N**2. https://www.netlib.org/lapack/explore-3.1.1-html/ssyevd.f.html closes scipygh-20512
Co-authored-by: Ralf Gommers <ralf.gommers@gmail.com>
…ith an infinite weight (scipy#20573) * Fix exact rotations at 180 deg, improve near 180 deg Comments * Tests for exact near 180 deg rotations * Fix tests * Code review updates --------- Co-authored-by: Scott Shambaugh <scottshambaugh@users.noreply.github.com>
* Apply "old version" of the patch provided at scipygh-20527
* Update the SciPy `1.13.1` release notes following a series of backports. [skip cirrus]
* Deals with the `spatial` part of scipygh-20623 (`Voronoi` was also affected beyond the originally-reported `Delaunay` segfault). * Both classes are documented to accept arrays with two dimensions only, so raise a `ValueError` in cases with other dimensions to avoid the segfault. * Other potential points of confusion here are the differences between arrays with two dimensions and two dimensional arrays that represent generators with more than two dimensions via the number of columns, but this is just how things are for most array programming languages of course. Also, the docs don't explicitly say array-like for the generators I don't think, but this patch only worked if I placed it after the coercion to array type. [skip circle] [skip ci] [ci skip]
* MAINT: stats: update boost to fix improve `skewnorm.ppf`
…d tests (scipy#20444) * test 1d input to sparse. Add FutureWarnings and ValueErrors * remove matrix changes. Let them create 2D * correct imports * rebase on main and update to support 1D CSR input
…oords) (scipy#20687) * test and then fix duplicates for CSR/CSC creation from (data,coords) * remove has_canonical_format check when summing duplicates.
[lint only]
Showed up as a linting error in an unrelated PR for me: ``` scipy/interpolate/_interpolate.py:918:30: UP032 [*] Use f-string instead of `format` call scipy/interpolate/_interpolate.py:1972:30: UP032 [*] Use f-string instead of `format` call ``` This should not happen; the old code is fine, so this check needs to be silenced or fixed separately. Similar to scipygh-20601. [skip ci]
* Fixes scipygh-19423 * Add a few more `case` statements to account for the (i.e., Windows) data types that don't have a fixed width, and add a regression test. [skip circle] [skip cirrus]
* attempt to deal with scipygh-20576
* some minor import fixes following a large series of backports
* more import cleanups after backport activity to make the linter happy
[skip circle]
* We're seeing CI failures related to an undesirable bump to Python `3.12` in this job, when the intention was clearly to respect the Python version specific in the GHA matrix. I didn't check too closely why exactly it suddenly started happening, but some packages weren't ready for `3.12` yet on this job (`scikit-umfpack` in particular) and I don't see too much harm in adding an extra pin to respect the intention for the Python version.
* attempt to fix `M1 test - openblas` MacOS ARM CI job based on some `gfortran` shims applied to a similar job on `main`
* This is an empty commit to test the wheel building in the above PR. [wheel build]
fa10b6c to
f96b8af
Compare
[wheel build]
f96b8af to
7c22416
Compare
tylerjereddy
pushed a commit
that referenced
this pull request
Jan 3, 2025
Callback for least_squares
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Debugging wheel builds for: scipy#20632