Marcus Müller
Marcus Müller
@jdemel, well, the only way for current/previously released C++ software that uses `lv_fc32_t` as `std::complex` not to break API is to leave it be `std::complex`, that's the API. However, not...
@jwakely exactly, all you can do is have a compatibility mode for this legacy software activated with a `#define`; afterwards, you can make the new API as sensible as you...
No, as most of the code in these assembler / optimized implementation files is not actually GPL, but MIT, BSD and others (e.g. `arch/x86/crypto/crc32c-pcl-intel-asm_64.S`)
you can't fix this without an API break, so break API in a visible, and useful manner, and completely remove the same-name C++ wrapper; instead of ```c++ void volk_32fc_x2_dot_prod_32fc(lv_32fc_t*, const...
pinging @evilynux here: You still up for fixing this code in a spare minute?
Don't we need to handle -1 in the calling functions to avoid calling into random memory?
By the way, how do we figure out what breaks finding that `generic` implementation? even if this PR was perfect in every way, it would *not* solve the underlying issue...
> liborc-dev is essentially a dependency and should be available anyways. liborc-**dev** should only be a build-time dependency, right?
So, to quickly write down what just happened: * github's "rename master to main" *deleted* the `master` reference, and introduced a `main` reference to the current HEAD of said branch....
> what about NaN? since (unsigned) ints don't "know" NaN, I'd be OK with defining that to be undefined behaviour, in the name of throughput. If you have a stream...