You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
vstruct uses a "safe, slow and stupid" approach to binary conversion that works in 5.1, 5.2, and luajit, and does not require binary loading, but is slow. It would be nice to have multiple implementations that it can combine at runtime, making use of 5.2's bit32 library and luaJIT's FFI when available, and possibly also having C implementations of some functions that it uses instead of the pure-lua versions if binary loading is available.
This would probably need multiple implementation directories (e.g. io/bin/, io/jit/, io/bit32/, and some kind of priority order; when it needs an IO handler it looks for the highest priority one that is actually available. This should be cached (I think this already happens, but maybe we're relying on require()'s cacheing, and this needs to be more intelligent than require()) so that don't go through the whole priority chain on every compile (or, worse, every IO operation). The pure-lua implementations are a fallback that's always available.
We may also want C/bit32 implementations of explode/implode, if there's a clean way to integrate them.
This also opens the door to supporting some IO formats that require these features, although I can't think of anything that would qualify offhand.
The text was updated successfully, but these errors were encountered:
vstruct uses a "safe, slow and stupid" approach to binary conversion that works in 5.1, 5.2, and luajit, and does not require binary loading, but is slow. It would be nice to have multiple implementations that it can combine at runtime, making use of 5.2's bit32 library and luaJIT's FFI when available, and possibly also having C implementations of some functions that it uses instead of the pure-lua versions if binary loading is available.
This would probably need multiple implementation directories (e.g. io/bin/, io/jit/, io/bit32/, and some kind of priority order; when it needs an IO handler it looks for the highest priority one that is actually available. This should be cached (I think this already happens, but maybe we're relying on require()'s cacheing, and this needs to be more intelligent than require()) so that don't go through the whole priority chain on every compile (or, worse, every IO operation). The pure-lua implementations are a fallback that's always available.
We may also want C/bit32 implementations of explode/implode, if there's a clean way to integrate them.
This also opens the door to supporting some IO formats that require these features, although I can't think of anything that would qualify offhand.
The text was updated successfully, but these errors were encountered: