hypirion / c-rrb Goto Github PK

I'd like to use Doxygen for documentation purposes. As I have never used Doxygen before, I'd be very happy if someone interested in contributing to this project and has used it before would like to set it up with me.

The essence of the algorithms manipulating the RRB-tree are described properly in my thesis, but is rather academic in nature and contains a lot of proofs.

The technicalities, however, aren't described as they are language-specific. To ease portability and understanding of the source, I'd like to add in proper explanation of each function, along with some comments on why things are done in the fashion they are. While I've tried to document some strange quirks, it's far from done.

Additionally, there's a big mismatch between development/master and experimental. Adding in some explanation on how experimental relates to development would be handy.

Theft is a c library for property-based testing. Moving tests over from the current setup will give us shrinking capabilities, better random generation of RRB-trees, and consequently better coverage of corner cases.

The functionality currently residing within rrb_debug.h has slowly evolved over time through what I needed for debugging, and is not really conforming to C calling conventions nor handling errors in a preferable way. These functions should be refactored to idiomatic C functions while retain the very "easy-to-use" functionality they have within lldb/gdb.

Should solve the issues mentioned in #1.

Hi,
maybe you can put a line for OSX users in the README file
as to what is required to build:

brew install boehmgc libtool

This was required on Mavericks,

Cheers
Jiri

Would you like to add the configuration script "AX_PTHREAD" to your build specification?

I would like to point out that identifiers like "_RRB" and "_TransientRRB" do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

I have some ideas on how loop unrolling could be done very efficiently. However, that is purely theoretical and would require performance measurements.

The idea is as follows: In almost all cases, we know how many iteration steps there will be before the actual iteration is done. Additionally, the code for a trie walk is exactly the same, with the possible exception of the last step. Henceforth, loop unrolling can, with some macro tricks, be done as shown on the experimental branch.

There are some other tricks which can be used as well, for example fact that any subtrie not containing a size table will never have a child with a size table (this is where it gets messy).

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• fopen ⇒ dot_file_create
• fprintf ⇒ label_pointer

Providing a refcount variant will make portability to non-GC languages (Rust, C++, etc.) easier.