Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BLD: Add libflame as a LAPACK back-end #13158

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 23, 2019
Merged

Conversation

zerothi
Copy link
Contributor

@zerothi zerothi commented Mar 19, 2019

This adds libflame to the available list of LAPACK implementations.

It requires #13132 before merging (which is why this is a draft for now!)

@charris
Copy link
Member

charris commented Mar 19, 2019

This will need a release note at some point.

@zerothi
Copy link
Contributor Author

zerothi commented Mar 20, 2019

@charris could you guide me towards this? Where should I add stuff? (note I already added flame to the documentation).

@zerothi zerothi marked this pull request as ready for review May 2, 2019 08:46
@rgommers rgommers self-assigned this May 2, 2019
@rgommers rgommers added this to the 1.17.0 release milestone May 2, 2019
@rgommers
Copy link
Member

rgommers commented May 2, 2019

Where should I add stuff?

If you could add a note on both this PR and gh-13132 to doc/release/1.17.0-notes.rst, that would be very helpful. Under "new features"

@zerothi
Copy link
Contributor Author

zerothi commented May 6, 2019

@rgommers could you see if 3b5b21c is fine?

Copy link
Member

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks @zerothi. I just suggested a few small tweaks.

Now libflame may be used as a LAPACK back-end.
libflame requires an external BLAS so one has to
also have this enabled.
Also added release notes for NPY_*_ORDER and libFLAME.
@zerothi
Copy link
Contributor Author

zerothi commented May 7, 2019

@rgommers I can't see why the Windows Python36 fails, but Windows Python37 does not... It seems I don't have permission to re-run the test?

@rgommers
Copy link
Member

rgommers commented May 7, 2019

Hmm, that looks unrelated but since it's in linalg I'd like to rerun the tests. Unfortunately I can't trigger a rerun either. @tylerjereddy could you trigger the rerun on Azure, and perhaps also add me ([email protected]) to the account?

@charris
Copy link
Member

charris commented May 7, 2019

I've triggered the re-run.

@tylerjereddy
Copy link
Contributor

Failure is still there for 32-bit Python 3.6 Windows, so maybe real. Various ways to debug--normally I'd set up Azure on a fork and play with the CI until I identify the specific test that crashes--maybe using a more verbose output.

@rgommers ok, you're an admin for NumPy Azure account now. Stephan Hoyer, Matti, and Chuck should also be admins.

@zerothi
Copy link
Contributor Author

zerothi commented May 23, 2019

@tylerjereddy @rgommers I am still very puzzled by the apparent show of linalg error in one build.
I haven't changed any default build-options, only enabled more.

Is there anything I can do?

@rgommers
Copy link
Member

Hmm the build logs for the failures have disappeared. I've triggered a re-run

@rgommers rgommers closed this May 23, 2019
@rgommers rgommers reopened this May 23, 2019
@rgommers rgommers merged commit 5962290 into numpy:master May 23, 2019
@rgommers
Copy link
Member

All green, in it goes. Thanks @zerothi!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants