Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

On macOS, the previous code chose int64_t as ssize_t, and int64_t is
defined as long long, but ssize_t had been defined as long (despite also
being 8 bytes).  This caused the typedef to be non-idempotent.

make_signed<size_t> chooses the right counterpart, depending on the base
type of size_t, e.g. unsigned long -> long, unsigned long long -> long
long, which is more robust when there are distinct base integer types
with the same size.

The CMakeLists.txt was installing everything in the
same directory, instead of creatin the proper subdirectories.

Modified the CMake to extract the path of the file and use the
path without the "src/" in the INSTALL()

Thanks to harmony-ek (github) for pointing it out.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

The documentation is in place and updated
even for the RAW API. a bit more testing
and we are done with v1

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Also: set the default thread number for concurrency
decoding of the RAW decoder to 1 (no concurrency)

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

De_Interleaver was not properly calculating
when to stop, and the decode_bytes was working with
old assumptions on de_interleaver.

fixed both

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Parts of it were not usable, other parts could
have been better

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

The linked version was not usable, and there were
inconsistencies. much better not, probably
still work to do.

The same will be done on the RFC wrappers

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Due to the wrking threads we can not really move
the RAW of RFC decoders.

We *can* move the wrappers, and *_void however.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

encode() was still expecting the symbol in
host endianness. the iterator was calling it
with the host endianness, too, so we did not notice.

The funny thing? The stable version was patched
correctly, and does not have this problem...

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Work for ticket #23



Get an RFC packet and add it to the decoder.
Not really tested :P

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Lots of bugs made any data taken from this binary
pretty useless. Now everything seems a bit more plausible.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

RAW API should be complete up to the C++ decoder
not included

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

block_size() optimistically reported the block size
as extracted from the partitioning. The problem
is that the last block is not always full, so the
last block had the wrong size.

report the right size

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

also a couple of other tests in there, but nothing
noteworthy, really

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Fixes #24



Sometimes it makes sense to have incomplete data.
This way we both de-interleave the incomplete data
and we give a std::vector<bool> of which bytes were
transmitted correctly and which were zeroed out.

Accessible through the end_of_input() calls, as it is the
only call that makes sense for this, since we need to
also ignore any other repair symbol.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Small optimization taken from OpenRQ.
Do not compute something that will not be
read again.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Things are much more stable and tested.
Documentation is still missing.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

The de_interleaver was still following the
raw esi (max_esi == extended_esi) instead of the
real number of symbols in the block.

Also a minor bugfix that probably does not change
anything in precode_solver

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Nothing of real value here

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

And I only found it by using this in an other project
..I really need some comprehensive tests...

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

2 bugs found in phase1

* wrong row tracking
* did not account for non_zero == 1

After looking at that code again, I think it needs a
small rewrite, some things could be a bit more efficient...

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Anders Martinsson authored Mar 15, 2018 and Luker committed Mar 16, 2018

Loop from 'i' to 'M' instead of 'i' to 'L' during Gaussian elimination in the
second phase.

Signed-off-by: Anders Martinsson <anders.martinsson@intinor.se>

This probably comes from a ill-fated idea to optimize and stop after the
triangular matrix is parsed, but that prevented us from parsing
other repair symbols. Which is really wrong.

Good work for ticket #21



Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

This table is used to generate random values
so this should help a lot towards fixing #20



Thanks to Anders Martinsson for reporting.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

We were doing really bad stuff.
* we were not using the correct block size, but instead
  creating something completely out-of standard
  This surely means that we were not compatible with
  OpenRQ (Ticket #20), and possibly a reason for which
  decoding fails too ofter (Ticket #21).
* We used the wrong ESI number, which should skip
  the padding numbers (#23, #20

)
* we did not expose the real block size to the user
  of the RFC namespace (RFC iterators)

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

We only report the number of symbols used in a block,
but you might want to know the size of the matrix we
use internally.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

The OTI fields and the symbol id are all in big endian.
We used the host endianness instead. fix that.

Ticket #22



Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

update docs: a variable was renamed to keep the
C and C++ versions in sync

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

...which brings some API breakage :(

notable things:

* C and C++ names for structs and variables are now in sync
* common.hpp is much easier to read
* added "trcked by" "tracks ..." to know that some things
  are to be kept in synch between C and C++
* "RaptorQ_Dec_Result" name was too similar to
  "RaptorQ_Decoder_Result". The C++ version calls it
  "Decoder_wait_res", let's go with that, at least it
  is more different and actually more to the point.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Just using wait() on the future does not give the
same semantic meaning as decode_once, which can sometimes
be needed.

Also, the C++ API exposes that, so the C API should really
track it.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

From is a void** not a void*

Copy-paste is as bad as ever, I guess...

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

I forgot to delete and set the ptr to nullptr
for the RaptorQ_ptr

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

marginlabels were improperly used instead of
subsubsections

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

Ticket #8



Finally move the documentation to track the
RFC6330 namespace for both C and C++ APIs

fixes are related to the documentation
* decode_symbol was forgotten
* future_state uniformed between RAW and RFC
* renamed a couple of RaptorQ__v1 in RFC6330__v1

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>

For Ticket #19

 C examples are needed, too.
Apparently the test/ directory is a bit complicated.

Signed-off-by: Luca Fulchir <luker@fenrirproject.org>