Use native sizes by default when parsing buffer format string#621
Merged
stevengj merged 4 commits intoJuliaPy:masterfrom Dec 10, 2018
Merged
Use native sizes by default when parsing buffer format string#621stevengj merged 4 commits intoJuliaPy:masterfrom
stevengj merged 4 commits intoJuliaPy:masterfrom
Conversation
Member
|
What is the AppVeyor failure? |
Contributor
Author
|
Just an fyi: with the appveyor failures before, it seems like the conda x64 environments might not have actually been 64-bit builds of Python. The tests were failing because the dtype of a |
This file contains hidden or 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
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.
Ahh oops. So, apparently you're supposed to use native sizes by default when parsing the buffer protocol format strings. I did the opposite in #487.
Current master
returns
Int32[1,0,1,0]*It should just be
Int[1,1,1,1]This actually caused me a bug in some relatively large distributed code, that I found very hard to track down. So karmically, pretty interesting.
At least it didn't make it to a release.
* The [1, 0, 1, 0] is also in part due to a bug in f_contiguous for 1d arrays when
stride != sizeof(T)- I will post a PR with a fix for that next week, I need to make some other changes to get the tests right for that. This is the minor positive to come out of this.