In the buffer protocol it used to advertise untyped data with B as the
format string, but the __getitem__ and __setitem__ were using the char
type (implicitly coming from the fact that the type exposed is
ArrayView<char>, StridedArrayViewND<char> or their const variants),
resulting in the data being treated as characters by Python. Which
was extremely annoying and inconsistent with how the bytes and bytearray
behaves.
Now ArrayView bindings always operate with std::uint8_t, and for
StridedArrayView there's a special case for the <char> type, which makes
it treated as std::uint8_t as well. Furthermore, to hint that the <char>
is "general data", the format string for it is null / None instead of B.
The time saved on not writing those messages back then was really not
worth the time wasted on figuring out what the hell every time one of
these fires.
And yet, somehow Python itself and a ton of libraries raises just an
IndexError alone, with nothing saying *how* wrong it was. Those details,
present in Magnum's own C++ asserts, proved to be extremely valuable for
being able to quickly figure out what's wrong, often even without even
having to look at the code or step through in the debugger.
Also fixes an issue where SceneData.field_object_offset() was rejecting
offsets right at the end of the field. Wasn't caught by tests because
apparently LookupError is a base of IndexError and as there was no
message it just failed elsewhere without being noticed.
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.
They're unpacked to full floats on element access and packed back from
full floats on mutable access, which makes this all very nice and
transparent. Yay Python!
That's it for now, I'll postpone half-float and matrix types for later
when these are actually needed, as it needs extra testing for the
aligned variants too.
To not have to duplicate these for each and every case, enlarging the
surface for potential bugs. Also changing the signatures to number +
identifier, instead of identifier repeated number of times. Means the
compiler won't be able to deduplicate / overlap the literals in the
binary, but is much more maintainable.
For Numpy this causes the slices to be reported as actual typed Numpy
arrays instead of typeless tuples, which is good I guess? Not sure why
that wasn't the case before, or what is the difference, and how it will
behave for sparse types such as aligned matrices.
It was casting in the wrong direction, causing an unbound type to be
returned and also accessing the data totally wrong. Should have tested
this properly in the first place.
Vladimír Vondruš