It should be preferred instead of Data:getPointer because the latter uses lightuserdata which can't store more all possible memory addresses on some new arm64 architectures, when LuaJIT is used.
All enum errors have (hopefully) been changed to a luax_enumerror, which has a
fixed error message. If additionally a list of valid options is passed, it
lists that in the error message. For every enum error with few options I've
implemented this using a getConstants call.
This solution has been designed specifically to reduce the number of template
instantiations (as I've been told that was a concern). All new template code
happens in places where there already was an instantiation of the relevant
StringMap. Of course there is still std::vector<std::string>...
--HG--
branch : minor
- Moved love.math.compress / decompress / decode / encode / hash to love.data.
- Changed love.data.compress/decompress to take the format argument first instead of second.
- Added love.data.newDataView. Returns a read-only subsection of an existing Data object.
- Added love.data.newByteData. Mostly useful in combination with LuaJIT's FFI as it has no extra methods currently.
- Added implementations of Lua 5.3's data packing APIs: love.data.packString / packData / unpack / getPackedSize.
Resolves issue #1336.
Resolves issue #1331.
--HG--
branch : minor