Conversation
|
Doc building is failing. There is a warning about missing files, but I don't think that is the cause: I couldn't rerun only the circleci CI. |
|
Yeah, no idea... just closing/reopening to see if that helps. |
bf86ada to
7aa9796
Compare
|
Still beats, me... @tupui maybe a long shot, but do you happen to know if this is known from pydata-sphinx-theme or so?! I don't see why this PR should include anything causing the build to trip building. The error is: (Which is clearly a malformed path, but one that seems unrelated to anything here.)
|
|
Does document building work locally? |
|
Ok while debugging this I hit a nasty segmentation fault which completely froze my computer. I'll try to describe what I did:
So, because I've seen similar issues before, I tried building the docs with no parallel execution (removed -j2 from the docs build command). This gave me a segmentation fault the first time I tried it, and froze my linux computer completely the second time. No idea what this is but it looks like something coming from sphinx... |
|
Docs seem to build fine with this PR checked out on an M3 Mac running Mac OS Sonoma. |
|
That all seems very reasonable. The only one of these that is used in SciPy is I can't say that it's immediately obvious to me what is going on there. |
7aa9796 to
a638f28
Compare
|
Well, let's see if rebasing magically fixes the doc build issue... I have not really tried to dig deeper into it after Melissa had a look. |
|
The build is still failing. My guess is that there is a segfault (maybe a header is still there but the implementation is missing?) in the worker thread, it dies without reporting anything, and the main thread can no longer communicate with it. Perhaps changing the doc build to non-parallel might expose the segfault? We are building with maybe the |
|
Are we just being stupid? We have We change API to break ABI, and in the rare case where it actually matters, our doc builds are bound to be broken until downstream is recompiled. EDIT: also |
Probably :) |
88714fa to
a638f28
Compare
|
Let's see if scipy/scipy#19656 is merged quickly. But I think I am willing to gamble and live with a briefly broken doc build until new downstream nightlies are uploaded. |
|
I'll get that SciPy PR merged and will see if I can get some new wheels up. There are a bunch of other failures preventing successful wheel uploads right now - we're kinda in circular dependencies territory at the moment. |
We never use them, they are an odd concept, as they pretend our doubles are Python doubles which they are not really (maybe once upon a time). The concept thus seems useless to me, nothing maps to a Python object clearly, and all integers map to Python ints with `.item()`, so what does it mean?
No idea, I don't think this was ever used in NumPy...
These are aliases around CopyInto and CopyAnyInto effectively, so move them to those slots.
I have not found a single use of this. In theory, it is designed to give 3rd party extensions access to your type number. In practice, 3rd parties using C doesn't really exist and should be able to get the descriptor object via Python.
We never use this, and it wasn't even documented...
How likely is it anyone needs to parse this, just use the type number directly.
It probably is also wrong if you use it on a field dict directly since it mangles up the order. The logic was designed for a *new* dtype creation from only a dict, and even there it is unclear that we should use it, since Python guarantees dict order... In either case, I can't imagine a reasonable use-case, we don't use it.
The function is what ensures that `np.empty()` leaves None objects rather than NULL to help others who don't take care to explicitly support NULL everywhere. It serves no other purpose and that purpose is exceedingly unlikely to be useful, especially since it requires dirty cleaning out of the original array first.
It's still terrible, but at least make it clear what it is used for...
There is no need anyone should really need these in C and getting the attribute isn't even so bad even if you do. I might have been convinced if this was documented, as is, the only usecase would be a custom arrayscalar and it can steal the flags from any of ours if it wants to...
a638f28 to
b6bc9c2
Compare
|
OK, scipy update is through and sufficient to make the docs build pass here. |
|
Btw. I think this one is ready to go in now. |
|
Thanks @seberg |
|
Hi - I just ran into this when attempting to compile |
|
It might be that our best option is to simply remove the highlighted code block, as the TODO there has been satisfied by the creation of the |
|
I thought you can just grab it from Python via |
|
Thanks @seberg - I'll give that a try. |
These removes some functions from the C-API that seemed rather uncontroversial to me. Many are undocumented, some just felt a bit odd without any real use-case.
From the release note as an overview:
PyArrayFlags_TypeandPyArray_NewFlagsObjectas well asPyArrayFlagsObjectare private now.There is no known use-case, use the Python API if needed.
PyArray_MoveInto,PyArray_CastTo,PyArray_CastAnyToare removeduse
PyArray_CopyIntoand if absolutely neededPyArray_CopyAnyInto(the latter does a flat copy).
PyArray_FillObjectArrayis removed, its only true use is forimplementing
np.empty. Create a new empty array or usePyArray_FillWithScalar()(decrefs existing objects).PyArray_CompareUCS4andPyArray_CompareStringare removed.Use the standard C string comparison functions.
PyArray_ISPYTHONis removed as it is misleading, has no knownuse-cases and easy to replace.
PyArray_FieldNamesis removed as it is unclear what it wouldbe useful for. It also has incorrect semantics in some possible
use-cases.
PyArray_TypestrConvertsince it seems a misnomer and unlikelyto be used by anyone. If you know the size or are limited to
few types, just use it explicitly, otherwise go via Python
strings.
I skipped removing
PyArray_CopyAnyInto, it is a raveling copy and that seems dubious to me, but OK. Having 3 aliases around felt unnecessary, though.The trickiest part is that I used the
Cast*slots for the new Copy as the functions are fully equivalent and it seemed nice in that corner of the table.PyArray_FillObjectArrayis also renamed and reduced to only filling withNone. It should be replaced, as the concept is quite problematic. I don't see it being used, otherwise the solution would be to tag on a big warning...FieldNamesis odd, because while we use the same logic in construction, I don't see users doing that. But if you use it to get the names, it reorders them, but name order is important, so that seems misleading.Should be rather straight forward, if someone feels strongly about being able to compile partial commits, squash them, as I only updated the C version at the end.