Changed those to be IndexError instead of ValueError, since those are
indexing dimensions. Plus added a new check for broadcasted dimension
size as otherwise it'd blow up on a C++ assert.
That's the way to go forward, StridedBitArrayView doesn't accept signed
numbers in every() anymore. Also extracted the slicing code to external
helpers in order to avoid duplication. Those will get reused in
[Strided]BitArray[View] bindings as well.
This should make self-contained builds *actually* working out-of-the
box, without having to fiddle with PATH or nasty copying of all DLLs
somewhere inside a Python installation.
These don't copy the data but rather reference the original with
different metadata. That caused use-after-free originally (if the input
variable got deleted or overwritten), the previous commit made it
assert (which was the intention there). Now it works properly.
This is important in case the data aren't owned by the instance but
instead referencing something else, for example the importer, a
memory-mapped file or another instance. Will get increasingly
important for zero-copy data import.
Right now the importer/converter APIs are not checked against the
features so using them wrong will assert and make Python die. But there
are at least the enums exposed now so it's possible to prevent the
assert.
They should be named after the plural EnumSet, not the C++ enum. That
was already done for the enums in the primitives library as well as all
shader flags, but not here. They should all also contain a NONE value
for an empty set.
Breaking change, sorry. To avoid similar mistakes in the future, this is
now documented in the API Conventions page.
In both PluginMetadata and AbstractPlugin itself. This makes the
pluginmanager module depend on the utility module (which currently
contains just the Configuration bindings).
It used to take an initializer list, not anymore. Will test this better
once I have to build e.g. AssimpImporter for some other reason -- then I
can use this function to prefer it for loading glTFs and see how that
manages.
Need that for configuring plugins -- originally thought I'd wait until
the class is reworked, but that isn't coming anytime soon given there's
insane pressure on other things, so I have to figure out a plan B.
The interface is the most barebones possible, exposing nothing that I'd
later plan to rename or remove. Just the least possible amount of APIs
to make it possible to configure plugins, and no custom type support yet
either -- if you need to write a vector, write it as a formatted string
instead, sorry.
To make it possible to test the APIs in isolation instead of through
the plugin interface, I added also a Configuration class. Also just the
least amount possible to cover the code with tests.
It was specific to Python 3.7, which is already EOL'd, so not much point
in investigating further. I won't deliberately make it broken there
though, so the order will stay maintained like this as much as possible.
Vladimír Vondruš